agentsclimarketplace

Motherduck duckdb sql

Skill motherduckdb/agent-skills/plugins/motherduck-skills/skills/motherduck-duckdb-sql

Opinionated AI agent skills for building applications with MotherDuck

Install
npx -y skills add motherduckdb/agent-skills --skill motherduck-duckdb-sql

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.

What its author says it does

Copied from the file, not written here

DuckDB SQL reference for MotherDuck. Use when you need exact DuckDB syntax or function behavior, friendly SQL features like QUALIFY, GROUP BY ALL, or list/struct types, MotherDuck-specific SQL such as shares, secrets, snapshots, or UNDROP, or to fix SQL errors and PostgreSQL-style SQL that fails on MotherDuck.

The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

3.0 KB, 562 tokens by cl100k_base, as published. Nobody here has run it

DuckDB SQL Reference for MotherDuck

Use this skill when you need exact DuckDB syntax, function behavior, or a quick sanity check that a statement will actually work on MotherDuck.

Source Of Truth

  • Prefer current DuckDB SQL docs for language features and function semantics.
  • Use current MotherDuck SQL docs for MotherDuck-only commands such as shares, secrets, snapshots, and Dive operations.
  • MotherDuck can lag upstream DuckDB releases for client compatibility; check MotherDuck version-lifecycle docs before promising newly released DuckDB syntax or types are available.
  • If the connection path matters, verify behavior against the current Postgres-endpoint docs before promising server-mode support.

Default Posture

  • Write DuckDB SQL, not PostgreSQL SQL, even when the client connects through the Postgres endpoint.
  • Use fully qualified "database"."schema"."table" names once more than one database or share is in scope.
  • Prefer DuckDB-native constructs when they simplify the query: GROUP BY ALL, QUALIFY, UNION BY NAME, arg_max, EXCLUDE, and REPLACE.
  • When porting SQL from another engine, translate functions, date arithmetic, identifier quoting, and type casts explicitly instead of assuming compatibility.
  • Verify current MotherDuck support before relying on recently released upstream DuckDB features such as VARIANT, native GEOMETRY, MERGE INTO, or date_trunc return-type changes.
  • Check whether the statement depends on local files, extension install/load, temporary-table behavior, or other client-only features before claiming it will work in MotherDuck.
  • Treat snapshot, restore, and UNDROP DATABASE statements as operational SQL with plan-specific retention behavior, not ordinary analytical syntax.
  • Treat MotherDuck SQL as an additional surface on top of DuckDB SQL, not a replacement for it.

Workflow

  1. Confirm the connection path and whether the question is about syntax, feature support, or a specific error.
  2. Write or repair the statement in DuckDB SQL first.
  3. Verify any MotherDuck-only command or server-mode limitation against the current docs.
  4. If the user needs exact syntax or function details, open references/SYNTAX_REFERENCE.md.

Open Next

  • Read references/SYNTAX_REFERENCE.md for DuckDB data types, friendly SQL features, functions, complex types, and common MotherDuck-specific gotchas.

Related Skills

  • motherduck-query for writing and validating analytical SQL against live MotherDuck data
  • motherduck-connect when syntax support depends on PG endpoint versus native DuckDB behavior
  • motherduck-explore when the problem is really missing schema context rather than missing syntax knowledge

Gives 0 of the 12 instructions most databases sql skills give in 562 tokens

Counted across 589 of the 662 authors here whose files we hold, read 2026-08-06

  • use parameterized queriesin 36 of 589, across 32 files
  • use timestamptz for timestampsin 30 of 589, across 12 files
  • create indexes concurrentlyin 29 of 589, across 23 files
  • index foreign keysin 28 of 589, across 17 files
  • use numeric type for moneyin 25 of 589, across 8 files
  • select only required columnsin 24 of 589, across 19 files
  • use cursor pagination instead of OFFSETin 23 of 589, across 15 files
  • add indexes manually on foreign key columnsin 22 of 589, across 11 files
  • read individual rule files for detailed explanationsin 18 of 589, across 4 files
  • configure connection poolingin 18 of 589, across 16 files
  • put equality columns before range columns in indexesin 17 of 589, across 9 files
  • normalize to third normal formin 17 of 589, across 8 files

Said here and by no other author read

  • write DuckDB SQL not PostgreSQL SQL
  • prefer DuckDB-native SQL constructs
  • translate SQL from other engines explicitly
  • verify MotherDuck support for new DuckDB features
  • check client-only feature dependencies
  • confirm connection path and question scope

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.