القائمة
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.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف 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.