From claude-swe-workflows
Performs pre-release readiness review: scans debug artifacts, version mismatches, changelog gaps, git hygiene, breaking changes, license compliance; runs tests and build verification for human review.
npx claudepluginhub chrisallenlane/claude-swe-workflows --plugin claude-swe-workflowsThis skill uses the workspace's default tool permissions.
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.
Creates isolated Git worktrees for feature branches with prioritized directory selection, gitignore safety checks, auto project setup for Node/Python/Rust/Go, and baseline verification.
Executes implementation plans in current session by dispatching fresh subagents per independent task, with two-stage reviews: spec compliance then code quality.
Dispatches parallel agents to independently tackle 2+ tasks like separate test failures or subsystems without shared state or dependencies.
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.
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 /review-doc 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 /review-doc. 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 /review-doc)
### Recommendation
PROCEED WITH CAUTION — 3 warnings remain
Commit changes?
> Yes
Committed: "chore: pre-release cleanup for v2.0.0"