motherduck-manage-guides

Manage MotherDuck Guides

Source Of Truth

• Prefer the current MotherDuck Guides documentation and MCP tool descriptions.
• For analytical queries through MCP, call get_query_guide before writing SQL, then traverse only relevant topics and Guides.
• get_dive_guide and get_flight_guide automatically include summaries from the reserved dives and flights topics; do not load those topics separately unless deeper context is needed.

Default Posture

• Keep one short root orientation Guide only when its guidance applies broadly. Put domain-specific knowledge under shallow, descriptive topics.
• Default new Guides to access = 'user'. Organization visibility requires an explicit request and the required admin permission; change it with set_guide_access (MCP) or --access on motherduck guide push.
• Document tables that Flights create under the data-sources topic (not flights, which holds authoring conventions): source, purpose, grain, key columns, transformations, refresh behavior, and caveats, with references to the table, its producing Flight, and any consuming Dive. Use organization access when the table's database has an owned share, user otherwise.
• Write one coherent subject per Guide, with a discriminating title and description. Lead with rules, tested SQL, and named pitfalls.
• Attach references to the databases, shares, schemas, tables, columns, Dives, Flights, or Guides the content governs so agents discover it at the right time.
• Validate referenced objects and executable SQL against the live workspace before presenting a Guide as trustworthy.
• Use version comments to explain why guidance changed. Read before update and avoid overwriting concurrent work.
• When a shell is available and Guides should live in Git or be reviewed like code, use motherduck guide (see motherduck-cli): edit guide.md locally, push with --version-description, and pass the commit SHA as --external-id so each version traces to a change.

Workflow

1. Inspect get_query_guide or list_guides to understand the visible topic tree and avoid duplication.
2. Read the relevant Guide versions and referenced objects before drafting a change.
3. Choose the narrowest useful topic; leave the topic empty only for organization-wide orientation.
4. Draft concise Markdown that maps business language to exact catalog objects and validated SQL.
5. For a create or update request, apply the change through MCP or the documented SQL function and read it back.
6. Verify metadata, access, references, current version, and change comment. For query work, follow the Guide and still validate the resulting SQL against the live schema.

For answer, review, or planning requests, inspect and draft without creating or modifying Guides. For explicit create/update requests, perform the in-scope mutation and verify it; ask before deletion or expanding visibility beyond the authorized audience. An explicit organization-publication request already authorizes that audience, subject to admin permission.

References

Read only the reference sections needed for the current task.

• Read references/GUIDES_PLAYBOOK.md for topic design, access governance, references, MCP/SQL operations, versioning, and quality checks.

Related Skills

Load related skills only for missing capabilities; reuse established context.

• motherduck-explore for validating referenced catalog objects
• motherduck-query for testing SQL and applying Guide-aware analysis
• motherduck-create-dive and motherduck-create-flight for reserved-topic conventions
• motherduck-security-governance for organization visibility and permission boundaries