Menú
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.
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
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.