Menu
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.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
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.
| name | release |
| description | 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. |
Releases are tag-driven: creating a GitHub Release publishes a tag, CI on the
release: published event builds the wheel/sdist and publishes to PyPI. You never
publish from a local machine (uv publish / twine upload are denied in
.claude/settings.json).
main)main, up to date with origin/main.task lint โ ruff format-check + lint pass.task test โ pytest at 100% coverage.uv build produces a wheel and confirm the wheel contains the bundled
SPA: python -m zipfile -l dist/dbdocs-*.whl | grep dbdocs/site/bundle should
list index.html + the assets/{js,css,vendor,graph}/ files. A wheel missing
dbdocs/site/bundle/** is broken โ fix the artifacts glob in
[tool.hatch.build.targets.wheel] of pyproject.toml before releasing.dbdocs follows semver. Choose patch/minor/major from the changes since the
last tag (git log <last-tag>..HEAD; git tag --sort=-v:refname | head shows
the latest โ the most recent published version is 1.0.2).[tool.hatch.version] source = "vcs") โ there is no static version in pyproject.toml to set. The tag you
create is the version. Tags are unprefixed X.Y.Z (e.g. 1.0.2), not
vX.Y.Z.CHANGELOG.md.gh release create X.Y.Z --title "X.Y.Z" --notes "<notes>" โ unprefixed tag
(matching the existing 1.0.2 style); this creates the tag and fires CI.gh run watch); capture the run ID for memory.pip install dbdocs==X.Y.Z in a throwaway env, then dbdocs --version.CHANGELOG.md.