dbt-docs

Use when changing how dbdocs assembles or presents the generated single-page-app — the project data dict, the external gzip payload (dbdocs-data.json.gz), the bundled 3-tier vanilla-JS SPA (index.html + assets/js,css,vendor), the React Flow graph bundle (frontend/), the vendored minisearch, or the versioned deploy layout.

Use when reading dbt artifacts or generating ERDs inside dbdocs — parsing manifest.json/catalog.json and producing Mermaid ERDs via the dbterd Python API for the generated Markdown pages.

Use when reviewing the generated dbdocs ERD's UI/UX against a real dbt project — the overview ERD and the model-page "Related ERD". Installs the local build into a target dbt project, generates + serves, drives a headless browser to screenshot both ERD surfaces (light/dark, default/focused), and emits a severity-graded UX findings report. ALWAYS asks for the dbt project path first.

Use when reviewing dbdocs changes (a diff, branch, or PR) for consistency, Python pluggability, design-pattern alignment, the 3-tier bundle-JS contract, complexity/scale, and the generated-SPA UX & accessibility. Produces a severity-graded findings report scoped to this codebase's documented patterns — not a generic lint.

Use when opening a pull request for dbdocs — pushes the current branch and creates a GitHub PR whose body follows .github/PULL_REQUEST_TEMPLATE.md (filled from the actual diff, with the right Type/Area boxes ticked and the checklist verified, not blindly checked). Mirrors the dbdocs-code-review skill's structure.

Use when cutting a release of the dbdocs package to PyPI. The single source of truth for the release procedure — pre-flight, version selection, GitHub Release creation, and post-publish verification.