From claude-swe-workflows
Pre-release readiness review that scans for debug artifacts, version mismatches, changelog gaps, git hygiene issues, breaking changes, and license compliance. Runs tests and build verification before presenting consolidated findings for human review.
How this skill is triggered — by the user, by Claude, or both
Slash command
/claude-swe-workflows:review-releaseopusThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Pre-flight checklist before cutting a release. Spawns a scanner agent for static analysis, runs execution-based checks (tests, build, doc freshness), then presents consolidated findings for human review. Runs all checks without interruption, then presents the full picture for decision-making.
Pre-flight checklist before cutting a release. Spawns a scanner agent for static analysis, runs execution-based checks (tests, build, doc freshness), then presents consolidated findings for human review. Runs all checks without interruption, then presents the full picture for decision-making.
Pairing with /release: This skill is the advisory side of the release seam. The mutator side is /release, which invokes /review-release as preflight before doing anything irreversible. If the intent is to cut the release, invoke /release directly — it runs this skill internally. Use /review-release standalone only when auditing readiness without committing to a cut.
Surface issues, don't silently fix them. A release is a commitment to users. Every issue deserves human review before shipping. The only auto-fixes offered are mechanical debug artifact removals.
Run everything, then report. Run all checks — static analysis, tests, build, doc freshness — without interruption. Present the full picture at the end so the user can make informed decisions with complete information.
Err toward reporting. A false positive costs seconds. A missed issue ships to users.
┌──────────────────────────────────────────────────────────┐
│ RELEASE REVIEW │
├──────────────────────────────────────────────────────────┤
│ 1. Determine release context │
│ 2. Spawn qa-release-engineer agent (static analysis) │
│ 3. Run test suite │
│ 4. Run build verification │
│ 5. Check documentation freshness │
│ 6. Present full consolidated report │
│ 7. User selects which items to address │
│ 8. Implement selected fixes │
│ 9. Re-verify affected checks │
│ 10. Final summary with release recommendation │
└──────────────────────────────────────────────────────────┘
Detect automatically:
git describe --tags --abbrev=0 (if no tags, note this)Ask the user two questions:
"What version are you releasing?" (Optional — enables version consistency checking against a target. If the user skips this, still check that all discovered versions agree with each other.)
"Any checks you want to skip?" Present options:
Prompt:
Perform a release readiness scan of this codebase.
Last tag: [tag or "none"]
Target version: [version if provided, else "not specified"]
Scope: entire codebase
Scan for: debug artifacts, version consistency, changelog coverage,
git hygiene, breaking changes, license compliance.
Return structured findings with severity levels (BLOCKER/WARNING/INFO).
Detect test command (try in order):
Makefile with test target → make testpackage.json with test script → npm testgo.mod present → go test ./...Cargo.toml → cargo testpyproject.toml or setup.py → pytest or python -m pytestRun the test command. Report:
Skip if user opted out in step 1.
Detect build command (try in order):
Makefile with build target → make buildpackage.json with build script → npm run buildgo.mod present → go build ./...Cargo.toml → cargo build --releasepyproject.toml with build config → detect build tool (python -m build, poetry build, etc.)Run the build command. Report:
Skip if user opted out in step 1.
Spawn doc-maintainer agent in assessment-only mode:
Perform a documentation freshness assessment only. DO NOT make any changes.
Review all documentation files (README, CHANGELOG, CLAUDE.md, doc/, etc.)
for staleness relative to the current codebase.
Report which documents appear outdated and what specifically seems wrong.
Add findings as WARNINGs. Include a note: "Run /tidy-docs to update documentation before release."
Merge all findings from steps 2-5 into a single numbered list:
## Release Readiness Report
Target: v1.3.0 (from v1.2.3, 47 commits)
### BLOCKERS (3)
1. [GIT] src/auth.go:42 — Merge conflict markers
2. [DEBUG] src/api/handler.go:15 — console.log("debug request body")
3. [TESTS] 2 test failures: TestPaymentFlow, TestAuthRefresh
### WARNINGS (4)
4. [CHANGELOG] Not updated since v1.2.3
5. [DEBUG] TODO markers in 3 files
6. [LICENSE] New dependency 'foo-lib' — unknown license
7. [DOCS] README.md references removed function parseConfig()
### PASSED
- Version consistency: All manifests agree (1.3.0)
- Build: Clean build successful
- Git hygiene: No large binaries, no tracked secrets
- Breaking changes: No undocumented API changes
Select items to address (e.g., "1-3", "all blockers", "all"):
Use AskUserQuestion with multi-select. Support shortcuts: "all blockers", "all warnings", "all", or specific numbers.
Group selected items by type and handle appropriately:
Handle directly as orchestrator. Remove the debug statement/line. Show the user what was removed.
Remove the marker comment. Show what was removed. The user selected these knowing they'd be deleted.
Cannot auto-fix — the user must resolve conflicts manually. Report the file and conflicting content. Skip.
Cannot auto-fix from here. Suggest: "Test failures require investigation. Fix manually or use /implement to address."
Cannot auto-fix from here. Report the error and suggest investigating.
Cannot auto-generate meaningful entries. Offer to scaffold a changelog entry by listing commits since last tag, organized by type (features, fixes, etc.). The user fills in the details.
If the user provided a target version, offer to update version numbers in manifest files to match. This is mechanical and safe for manifests. For source code constants, show the file and line — the user confirms.
Report only. The user must decide whether the dependency is acceptable.
Suggest running /tidy-docs. Do not attempt fixes.
Report only. The user must decide whether to document, revert, or accept.
After implementing fixes, re-verify only the checks that were affected:
Do NOT re-run the full test suite or build at this step (the user can do that separately). Only re-verify the fast, static checks.
## Release Review Complete
### Status
- BLOCKERS resolved: 2/3 (1 requires manual fix)
- WARNINGS addressed: 2/4
- Items skipped: 3 (user declined)
### Changes Made
- Removed 1 console.log statement (src/api/handler.go:15)
- Removed 3 TODO markers
### Remaining Issues
- [BLOCKER] Merge conflict markers in src/auth.go — manual resolution needed
- [WARNING] CHANGELOG.md not updated
- [WARNING] New dependency 'foo-lib' license unverified
### Recommendation
HOLD — 1 unresolved BLOCKER remains
Recommendation logic:
If changes were made, ask the user if they want to commit:
git add [specific files modified]
git commit -m "$(cat <<'EOF'
chore: pre-release cleanup
[Brief description of what was removed/fixed]
EOF
)"
Sequential execution:
Agents used:
qa-release-engineer: Static analysis scan (step 2)doc-maintainer: Documentation freshness assessment only (step 5)State to maintain (as orchestrator):
Abort workflow:
Do NOT abort for:
Test commands (try in order):
Makefile with test target → make testpackage.json with test script → npm testgo.mod → go test ./...Cargo.toml → cargo testpyproject.toml or setup.py → pytestBuild commands (try in order):
Makefile with build target → make buildpackage.json with build script → npm run buildgo.mod → go build ./...Cargo.toml → cargo build --releasepyproject.toml with build config → python -m build> /review-release
What version are you releasing?
> 2.0.0
Any checks to skip?
> Run everything
Spawning qa-release-engineer agent for static analysis...
Running tests: go test ./...
Running build: make build
Checking documentation freshness...
## Release Readiness Report
Target: v2.0.0 (from v1.9.2, 89 commits)
### BLOCKERS (2)
1. [DEBUG] src/api/handler.go:15 — fmt.Println debug statement
2. [VERSION] Version not bumped to 2.0.0 (currently 1.9.2)
### WARNINGS (4)
3. [CHANGELOG] Not updated since v1.9.2
4. [BREAKING] Removed ParseConfig() — not in changelog
5. [DEBUG] TODO markers in 2 files
6. [DOCS] README.md references removed ParseConfig()
### PASSED
- Tests: All pass
- Build: Clean
- Git hygiene: Clean
- License: Compatible
Select items to address:
> 1, 2, 5
Removing debug statement from src/api/handler.go:15... done.
Updating version to 2.0.0 in package.json... done.
Updating version to 2.0.0 in src/version.go... done.
Removing TODO markers from src/migrate.go:12, src/config.go:55... done.
Re-verifying... no debug artifacts remain, versions consistent.
## Release Review Complete
### Status
- BLOCKERS resolved: 2/2
- WARNINGS addressed: 1/4
- Items skipped: 3 (user declined)
### Changes Made
- Removed 1 debug statement (src/api/handler.go:15)
- Updated version to 2.0.0 in package.json, src/version.go
- Removed 2 TODO markers
### Remaining Issues
- [WARNING] CHANGELOG.md not updated
- [WARNING] Removed ParseConfig() not documented as breaking change
- [WARNING] README.md references removed function (run /tidy-docs)
### Recommendation
PROCEED WITH CAUTION — 3 warnings remain
Commit changes?
> Yes
Committed: "chore: pre-release cleanup for v2.0.0"
npx claudepluginhub chrisallenlane/claude-swe-workflows --plugin claude-swe-workflowsAudits an npm project for release readiness with packaging, documentation, and dependency checks. Blocks releases on failures.
Validates pre-release readiness by reviewing diffs, changelogs, CI status, tests, and artifacts. Guides versioning, release notes, smoke tests, and rollback planning.
Final code review skill: runs stack-specific tests/lints (Next.js, Python, Swift, Kotlin), security checks, verifies spec.md criteria, audits hub files, issues ship/no-go verdict after /build or /deploy.