full-review

Full Review

Answer "perform a full review", "final check before release", or "make sure everything works and is up to date" with one deep pass that ends in a fixed, proven tree. The default outcome is applied verified fixes, not a findings list. repository-review owns read-only audits and severity. Unlike the recurring repository-maintenance upkeep pass, this skill inventories and reads every tracked area across all dimensions below, then fixes and proves the result with the full gate. When a repository ships its own verify skill (such as dot-verify), follow it and use this skill only for what it omits.

Arguments

Parse the request into one line and state it before starting: scope (paths, other repositories), exclusions ("skip data/"), depth (default deep: every tracked file in scope), mode (default fix; report stays read-only, skips the Fix and Prove steps, and lists findings under Fixed renamed Findings, ranked by repository-review severity), and follow-ups (release, commit, propagation; none unless requested). Ask only when an ambiguity changes scope, cost, or reversibility.

Workflow

1. Baseline: record git status --short, staged and unstaged diffs, the last tag, and git fetch state. Existing uncommitted work is part of the candidate unless the user says otherwise; never discard or restage it. Run the existing gates once to separate preexisting failures from regressions.
2. Load decisions: read AGENTS.md, README.md, skills, changelog, and stored decisions (agent memory, ## Decisions notes, ADRs). Do not re-raise kept or declined choices; mention one only when a new change reopens it.
3. Inventory coverage: list tracked files by area with git ls-files, minus exclusions and generated or vendored files. Track each area to reviewed; "don't scratch the surface" means no unread area. For large trees, fan out read-only reviews by area to subagents or one session per area when the host supports it, then verify every returned finding yourself before acting.
4. Review each dimension in the review matrix, plus what reviews here repeatedly request:
   • Works: every task and CLI entry point runs clean with no warnings (smoke); production or deployed endpoints are probed read-only when they exist.
   • Current: tools, dependencies, actions, and runtimes against their latest releases (upgrade-tools); report drift and upgrade when the request says so.
   • Simple: dead code, legacy paths, orphan files, stale config, unearned abstractions, and verbose docs (trim); prefer deletion and consolidation, never a heavier mechanism.
   • Consistent: names, descriptions, versions, and metadata match across code, pyproject.toml, docs, GitHub (github-repository), and the website; ignore files fit the stack (update-ignores).
   • Secure and private: secrets, permissions, dependencies, and agent tools (code-security); private repositories stay private and public ones disclose nothing sensitive.
   • Documented: README.md, AGENTS.md, skills, and *.md match behavior, stay concise, and convince their audience (repository-docs).
   • Fast: slow tasks, tests, CI, or pages with a measured cause (benchmark).
5. Fix: apply each verified finding with the smallest change; add a regression test for behavior fixes. Prefer one coherent change per finding so selective reverts stay easy. Hold back changes that are irreversible, outward-facing, costly, or that change a deliberate design, and list them as decisions.
6. Prove: rerun only the checks a fix invalidated, then the full gate (mise run all or the repository's equivalent) on the final tree. Confirm the tested snapshot equals the candidate.
7. Report: per the template below. Keep it short; evidence goes in file:line references, not narration.
8. Follow up on request: release or commit through git-delivery or the repository's release skill; propagate to dependent repositories by repeating this pass there; when the user says "apply all" after a report-mode run, resume at the Fix step.