wads

Full health diagnosis and improvement dispatch for a wads-managed Python repo (uv-ci stub, i2mint conventions). One read-only audit across every dimension — legacy packaging, CI generation and status, PyPI/pyproject version sync, PyPI metadata, tests, docstrings, docs publishing, GitHub metadata drift, type annotations/py.typed, import time, changelog, agent skills — then a prioritized health report and dispatch to specialist skills one dimension at a time. Use for "diagnose this repo", "repo health check", "what's wrong with this repo", "audit this package", "doctor this repo", "how healthy is this project", "bring this repo up to standard", "what should I improve here". Also trigger when the user names a repo and wants a general improvement pass. Does NOT itself migrate, debug CI, write tests, or fix docstrings — it diagnoses, prioritizes, and routes to the owning specialist skills. Only GitHub metadata alignment is fixed inline.

Point-in-time CI health snapshot for a single wads-managed Python repo (one using the i2mint uv-ci stub or inline uv workflow). Checks five things and reports a checklist: is CI green, is ci.yml the current stub (and how it's pinned), are the secrets wired correctly across the two layers, is the version in sync between pyproject/PyPI/git tags, and is docs publishing (Pages, Discussions) healthy. Use when the user asks "is CI green", "check CI health", "why didn't it publish", "is this repo's CI up to date", "are my CI secrets set up right", "is PyPI in sync with pyproject", "give me a CI snapshot", or "health-check this repo's CI". Diagnosis only — fixes are delegated: format migration → wads-migrate, push-back/version-sync repair → wads-ci-fix, fleet/batch work → wads-ci-sweep, Pages repair → epythet-docs. Does NOT cover generic CI strategy or non-wads pipelines — use ci-advisor or ci-setup for those.

Use when migrating Python projects to modern wads setup (pyproject.toml + uv CI). Triggers on migration tasks, CI modernization, setup.cfg conversion, switching from pip to uv, or moving a repo from inline uv CI to the reusable-workflow stub.

The skills step of a wads repo-improvement pass: assess whether a repo warrants AI agent skills (baseline: a consumer + a dev skill) and dispatch the work. Layout, distribution, and spec compliance are DEFERRED to the canonical authority — the `skill-package-setup` skill in the `skill` package. Use when the user says "skillify this repo", "does this repo need skills", "set up skills for this project", "where should skills live", "restructure the skills layout", "align/validate my skills", "make skills gh-skill compatible", or "why doesn't Claude Code see this repo's skills". Also trigger as the skills step of a repo health pass (wads-repo-doctor). Does NOT author skill content (skill-build / skill-creator), write README docs (skill-docs), or fix content drift (skill-sync).

Diagnose and close test-coverage gaps in a wads-managed Python repo (pytest + doctests + uv CI). Measures coverage exactly as CI does (doctests included), adds branch coverage and per-test contexts, buckets every public function/class as untested / doctest-only / test-covered, then writes the missing tests. Use for "what's untested", "check test coverage", "coverage gaps", "which functions have no tests", "is this only covered by doctests", "improve coverage", "raise coverage", "write tests for the uncovered parts", "add tests for this module". Also trigger when CI coverage numbers look wrong or a doctest-heavy package looks untested. Does NOT analyze failing-test output (pipe pytest output to the wads-test-analyze CLI), measure docstring presence (wads-docs-coverage), or check CI workflow health (wads-ci-health).

Documentation coverage for a wads-managed Python repo: diagnose, align, complete. Measures docstring presence (every module, class, and function), executes the README's code blocks to prove they still run, cross-checks README names and install lines against the live API, and detects signature↔docstring drift; then proposes removals for obsolete docs and writes missing Google-style docstrings (with doctests) and README sections. Use when the user says "audit the docs", "docs coverage", "what's missing docstrings", "write the missing docstrings", "is the README up to date", "check the README examples", "the README mentions things that don't exist", or "docstring coverage report". Also trigger after a refactor or rename that may have stranded docs, or when CI lint flags D1xx missing-docstring errors. Does NOT fix RST/Sphinx rendering mistakes (use wads-docstring-render), does NOT cover docs publishing, GitHub Pages, or 404s (use epythet-docs), and does NOT measure test coverage (use wads-test-coverage).

Generate and maintain CHANGELOG.md for a wads-managed repo (one where CI auto-bumps the version and tags releases with bare version tags like 0.2.3) from git history. Diagnoses coverage (does a changelog exist, latest tag vs latest version covered, gap list), generates Keep-a-Changelog-style sections per version tag with CI noise filtered (bump commits, [skip ci] housekeeping, bare merges) and PR titles kept verbatim, and maintains the file idempotently: only inserts sections for missing versions, never rewrites hand-edits. Use for "generate a changelog", "create CHANGELOG.md", "update the changelog", "is the changelog up to date", "backfill the changelog", "what changed in 0.2.3", "release notes from git history", "changelog is behind the releases". Also trigger when wads-repo-doctor reports a missing/stale changelog. Does NOT add the [project.urls].Changelog link or polish PyPI metadata (wads-pypi-polish), and does NOT diagnose version-sync or CI problems (wads-ci-health).

Find and fix docstrings that mis-render under epythet (Sphinx + RST + napoleon): single backticks showing as italics, doctests glued into paragraphs, literal "Returns:" or ":param" text, red asterisks from bare *args, collapsed bullet lists, markdown fences, smartquote-corrupted code. Use for "fix my docstrings", "the API docs render wrong", "my doctest shows as plain text", "why is this italic in the docs", "red asterisks in the docs", "Returns: shows literally on the page", "audit docstring RST", "make docstrings Sphinx-clean", "the published module page looks mangled". Also trigger after writing new docstrings or before a docs release. Does NOT cover docs publishing, GitHub Pages, or 404s (use epythet-docs), and does NOT measure docstring presence/coverage or README drift (use wads-docs-coverage).

Audit and improve import time and import hygiene in a wads-managed Python repo. Measures `python -X importtime` (warm-cache, against the local checkout), ranks heavy modules and third-party offenders, verifies every module imports standalone (CI runs pytest --doctest-modules, which imports every module), cross-checks unguarded module-level imports of undeclared/extra-only packages, then makes imports lazy and clean (function-local imports, TYPE_CHECKING, PEP 562 module __getattr__, guarded optional deps). Use for "why is import so slow", "speed up import", "make imports lazy", "audit imports", "import hygiene check", "this module breaks --doctest-modules", "optional dependency breaks import", "lighten the core install". Also trigger when CI fails at collection with ImportError/ModuleNotFoundError before any test runs. Does NOT do full declared-vs-imported dependency drift (use the wads-deps CLI), measure test coverage (wads-test-coverage), or diagnose CI wiring (wads-ci-health).

Audit and improve a package's pyproject.toml so its PyPI page looks professional, is discoverable in search, and signals quality. Use when the user wants to "polish pyproject.toml", "make my PyPI page look professional", "improve PyPI discoverability", "add classifiers / keywords / project URLs", "add badges", "review my package metadata", "why does my PyPI page look bare", or prepare a package for publishing/release. Adds and validates description, readme, license (SPDX), requires-python, keywords, trove classifiers, and project.urls with PyPI-recognized labels; recommends README badges and quality signals (coverage, lint, typing). Does NOT change code, dependencies, or versions; CI/publishing state belongs to wads-ci-health, docs publishing (Pages/Sphinx) to epythet-docs.

Type-annotation coverage for a wads-managed Python repo: diagnose, complete, decide py.typed. Measures public-API type completeness with pyright --verifytypes (per-symbol score), produces an agent-actionable missing-annotation work list (ruff ANN rules, JSON), checks whether py.typed exists and actually ships in the wheel, then writes the missing annotations duck-typing-first (collections.abc, Protocol) and advises when adding py.typed is justified. Use for "type coverage", "how typed is this package", "add type annotations", "annotate the public API", "should I add py.typed", "is this package typed", "type completeness score", "make this PEP 561 compliant", "mypy strict cleanup". Also trigger when downstream users report missing-stub or Unknown-type complaints about the package. Does NOT set the Typing :: Typed classifier or other PyPI metadata (wads-pypi-polish), measure test or docstring coverage (wads-test-coverage / wads-docs-coverage), or fix import-time slowness found along the way (wads-import-time).

Use when the user wants to create a new Python project/package, name a project, set up a GitHub repo, or bootstrap a project from scratch. Triggers on requests like "help me set up a project", "create a package", "I need a name for...", "new repo for...".