pre-release-audit

/pre-release-audit

Run a pre-release checklist and report what's ready, what's not, and what needs attention.

Steps

1. Uncommitted changes — Run git status. Flag any modified or untracked files.
2. Current branch — Run git branch --show-current. Warn if not on the expected release branch.
3. Version consistency — Find all version references:
   • pyproject.toml (Python: version = "...")
   • package.json (Node: "version": "...")
   • Cargo.toml (Rust: version = "...")
   • CHANGELOG.md (most recent entry version)
   • Any other manifest files Compare them. Flag any mismatch.
4. Tests — Check if a test suite exists. If pyproject.toml is present: note cd cli && uv run pytest status (run if possible). Same for package.json → npm test.
5. Lint — Check for lint config (.ruff.toml, .eslintrc, etc.). Note the lint command and run if possible.
6. CHANGELOG.md — Check that it exists and has an entry for the current version (not just [Unreleased]).
7. Open items — Look for TODO, FIXME, HACK in recently changed files (git diff HEAD~5..HEAD). Flag any that seem release-blocking.
8. Dependencies — If a lock file exists (uv.lock, package-lock.json, Cargo.lock), check that it's committed.

Output Format

## Pre-Release Audit

### ✅ Ready
- [item]: [detail]

### ❌ Blocking
- [item]: [what's wrong and where to fix it]

### ⚠️ Needs Attention
- [item]: [what to check]

### ⬜ Could Not Check
- [item]: [why — missing credentials, tool not available, etc.]

---
**Summary:** X of Y checks passing. [Release-ready | Not ready — see blocking items above]

Rules

• Be specific: file paths, line numbers, exact version strings
• Only mark something ❌ Blocking if it would likely cause a production issue
• Don't fail a release for stylistic preferences — focus on correctness
• If you can't run a check (no permission, missing tool), put it in ⬜ rather than guessing