/motherduck-partner-delivery
Deliver repeatable MotherDuck architectures across multiple clients. Use when a consultancy, agency, or multi-client product team needs to standardize isolation, provisioning, regional deployment, sharing boundaries, and client-specific exceptions across client engagements.
$ npx -y skills add motherduckdb/agent-skills --skill motherduck-partner-delivery --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.
- You can call itInvoke it directly when you want it.
- Slash command
/motherduck-partner-delivery
Context preview
The summary Claude sees to decide when to auto-load this skill.
Deliver repeatable MotherDuck architectures across multiple clients. Use when a consultancy, agency, or multi-client product team needs to standardize isolation, provisioning, regional deployment, sharing boundaries, and client-specific exceptions across client engagements.
SKILL.md
motherduck-partner-delivery.SKILL.mdname: motherduck-partner-delivery
description: Deliver repeatable MotherDuck architectures across multiple clients. Use when a consultancy, agency, or multi-client product team needs to standardize isolation, provisioning, regional deployment, sharing boundaries, and client-specific exceptions across client engagements.
license: MIT
Partner Delivery
Use this skill when a consultancy, implementation partner, or multi-client product team needs a repeatable MotherDuck delivery pattern across several clients.
This is a use-case skill. It orchestrates `motherduck-connect`, `motherduck-explore`, `motherduck-model-data`, `motherduck-query`, `motherduck-share-data`, and `motherduck-create-dive`.
Start Here: Is a MotherDuck Server Active?
- If a **remote MotherDuck MCP server** or **local MotherDuck server** is active, use it.
- Discover the client databases or workspaces from the active context. Ask only when multiple plausible targets remain and the choice would materially change the delivery model.
- Explore the live setup when available:
- current client database boundaries
- regional layout
- existing service-account or share boundaries
- reusable schemas vs client-specific schemas
Use that discovery to decide what can be standardized and what must stay client-specific.
If no server is active, use any supplied client and region context. For planning work, proceed with explicit assumptions when safe; ask for missing details only when they block a reliable result.
Delivery Defaults
- structural isolation over query-time tenant filtering
- one client database or stronger boundary per client
- shared architecture, client-specific schema
- explicit sharing and revocation per client
- versioned templates for provisioning, validation, handoff, and exception tracking
Workflow
1. Inspect the available MotherDuck server or supplied client context. 2. Classify the client patterns. 3. Inspect the existing regional and database layout if available. 4. Standardize the architecture and provisioning path. 5. Define the repeatable validation pack for every client environment. 6. Document client-specific exceptions. 7. Produce the handoff assets and validation checks.
Match execution to the request: answer, review, or planning work returns the requested delivery artifacts; build or change work creates the requested in-scope templates or client assets and validates them. Ask before provisioning additional client environments, destructive changes, or external writes not already authorized.
When this skill produces a native DuckDB (`md:`) connection, watermark it with `custom_user_agent=agent-skills/2.5.0(harness-<harness>;llm-<llm>)`. If metadata is missing, fall back to `harness-unknown` and `llm-unknown`.
Output
The output of this skill should be:
- the default multi-client pattern
- the standard provisioning checklist
- the region and isolation posture
- the client-specific exceptions
If the caller explicitly asks for structured JSON, return raw JSON only with no Markdown fences or prose before/after it. This is mainly for automated tests, regression checks, or downstream tooling that needs a stable machine-readable shape. Normal human-facing use of the skill can stay in prose unless JSON is explicitly requested.
Use this exact top-level shape when JSON is requested:
{
"summary": {},
"assumptions": [],
"implementation_plan": [],
"validation_plan": [],
"risks": []
}References
Read this as reference, not as a script to execute:
- `references/PARTNER_DELIVERY_GUIDE.md` -- default multi-client pattern, standardize-versus-client-specific split, shares-versus-Dives-versus-apps choice, region/compliance handling, and provisioning starters
Runnable Artifact
- `artifacts/client_delivery_example.py` -- MotherDuck-backed Python example showing one database namespace per client and a simple validation pass across client environments
- `artifacts/client_delivery_example.ts` -- TypeScript companion artifact with the same delivery output contract
Run it with:
uv run --with duckdb python skills/motherduck-partner-delivery/artifacts/client_delivery_example.py
Run the same artifact against temporary MotherDuck databases:
MOTHERDUCK_ARTIFACT_USE_MOTHERDUCK=1 \
uv run --with duckdb python skills/motherduck-partner-delivery/artifacts/client_delivery_example.py
Validate the TypeScript companion artifact:
uv run scripts/test_typescript_artifacts.py
Related Skills
- `motherduck-connect` -- standardize the connection path
- `motherduck-explore` -- inspect existing client workspaces and boundaries
- `motherduck-model-data` -- design client-specific schemas
- `motherduck-query` -- validate core metrics and data contracts
- `motherduck-share-data` -- publish governed share boundaries
- `motherduck-create-dive` -- create repeatable client-facing answer surfaces when needed
Read more
name: motherduck-partner-delivery description: Deliver repeatable MotherDuck architectures across multiple clients. Use when a consultancy, agency, or multi-client product team needs to standardize isolation, provisioning, regional deployment, sharing boundaries, and client-specific exceptions across client engagements. license: MIT
Partner Delivery
Use this skill when a consultancy, implementation partner, or multi-client product team needs a repeatable MotherDuck delivery pattern across several clients.
This is a use-case skill. It orchestrates `motherduck-connect`, `motherduck-explore`, `motherduck-model-data`, `motherduck-query`, `motherduck-share-data`, and `motherduck-create-dive`.
Start Here: Is a MotherDuck Server Active?
- If a **remote MotherDuck MCP server** or **local MotherDuck server** is active, use it.
- Discover the client databases or workspaces from the active context. Ask only when multiple plausible targets remain and the choice would materially change the delivery model.
- Explore the live setup when available:
- current client database boundaries
- regional layout
- existing service-account or share boundaries
- reusable schemas vs client-specific schemas
Use that discovery to decide what can be standardized and what must stay client-specific.
If no server is active, use any supplied client and region context. For planning work, proceed with explicit assumptions when safe; ask for missing details only when they block a reliable result.
Delivery Defaults
- structural isolation over query-time tenant filtering
- one client database or stronger boundary per client
- shared architecture, client-specific schema
- explicit sharing and revocation per client
- versioned templates for provisioning, validation, handoff, and exception tracking
Workflow
1. Inspect the available MotherDuck server or supplied client context. 2. Classify the client patterns. 3. Inspect the existing regional and database layout if available. 4. Standardize the architecture and provisioning path. 5. Define the repeatable validation pack for every client environment. 6. Document client-specific exceptions. 7. Produce the handoff assets and validation checks.
Match execution to the request: answer, review, or planning work returns the requested delivery artifacts; build or change work creates the requested in-scope templates or client assets and validates them. Ask before provisioning additional client environments, destructive changes, or external writes not already authorized.
When this skill produces a native DuckDB (`md:`) connection, watermark it with `custom_user_agent=agent-skills/2.5.0(harness-<harness>;llm-<llm>)`. If metadata is missing, fall back to `harness-unknown` and `llm-unknown`.
Output
The output of this skill should be:
- the default multi-client pattern
- the standard provisioning checklist
- the region and isolation posture
- the client-specific exceptions
If the caller explicitly asks for structured JSON, return raw JSON only with no Markdown fences or prose before/after it. This is mainly for automated tests, regression checks, or downstream tooling that needs a stable machine-readable shape. Normal human-facing use of the skill can stay in prose unless JSON is explicitly requested.
Use this exact top-level shape when JSON is requested:
{
"summary": {},
"assumptions": [],
"implementation_plan": [],
"validation_plan": [],
"risks": []
}References
Read this as reference, not as a script to execute:
- `references/PARTNER_DELIVERY_GUIDE.md` -- default multi-client pattern, standardize-versus-client-specific split, shares-versus-Dives-versus-apps choice, region/compliance handling, and provisioning starters
Runnable Artifact
- `artifacts/client_delivery_example.py` -- MotherDuck-backed Python example showing one database namespace per client and a simple validation pass across client environments
- `artifacts/client_delivery_example.ts` -- TypeScript companion artifact with the same delivery output contract
Run it with:
uv run --with duckdb python skills/motherduck-partner-delivery/artifacts/client_delivery_example.py
Run the same artifact against temporary MotherDuck databases:
MOTHERDUCK_ARTIFACT_USE_MOTHERDUCK=1 \ uv run --with duckdb python skills/motherduck-partner-delivery/artifacts/client_delivery_example.py
Validate the TypeScript companion artifact:
uv run scripts/test_typescript_artifacts.py
Related Skills
- `motherduck-connect` -- standardize the connection path
- `motherduck-explore` -- inspect existing client workspaces and boundaries
- `motherduck-model-data` -- design client-specific schemas
- `motherduck-query` -- validate core metrics and data contracts
- `motherduck-share-data` -- publish governed share boundaries
- `motherduck-create-dive` -- create repeatable client-facing answer surfaces when needed
Opinionated AI agent skills for building applications with MotherDuck
Other skills on motherduckdb-agent-skills.
- /motherduck-build-cfa-app
Design a MotherDuck-backed customer-facing analytics app. Use for embedded analytics, multi-tenant SaaS reporting, or product analytics for external users -- whenever the decision depends on per-customer isolation, backend routing, service-account boundaries, read scaling, or
Open skill - /motherduck-build-dashboard
Build a live MotherDuck dashboard as a Dive. Use when composing one shareable KPI, trend, and breakdown story over existing MotherDuck data, especially when the result should stay a saved workspace artifact rather than a full application.
Open skill - /motherduck-build-data-pipeline
Design an end-to-end MotherDuck data pipeline. Use for ETL/ELT workflows -- choosing raw, staging, and analytics boundaries, bulk ingestion paths, transformation sequencing, dlt/dbt integration, publication targets, or whether DuckLake is actually required.
Open skill - /motherduck-connect
Connect to MotherDuck from any application. Use when setting up database connectivity via the Postgres endpoint (recommended), pg_duckdb, native DuckDB API, or JDBC. Covers connection strings, authentication, SSL, and environment variable configuration.
Open skill - /motherduck-create-dive
Create, edit, manage, share, or embed MotherDuck Dives — live React + SQL dashboards, charts, and data apps saved in the workspace. Use for any dashboard, chart, KPI display, or data visualization over MotherDuck data, and for Dive authoring mechanics such as get_dive_guide,
Open skill - /motherduck-create-flight
Create, schedule, run, and debug MotherDuck Flights — Python jobs that run on MotherDuck compute. Use whenever someone wants to create a flight, schedule a Python script or recurring job on MotherDuck, set up scheduled ingestion from Postgres, dlt sources, S3, BigQuery,
Open skill

