Release Prep Checklist

Validates that the repository is in a clean, releasable state. Does not create tags, bump versions, or push commits — release-please automation manages all of that from main. The only action this skill takes beyond validation is offering to open a PR, and only after every gate passes and the user explicitly approves.

Run these steps in order. Stop immediately and report findings to the user if any step fails. Do not proceed to the next step.

Step 1 — Validate All Skills and Version Sync

Run /validate-skills. This validates both public skills (skills/*/SKILL.md) and internal skills (.claude/skills/*/SKILL.md), and also runs the version-sync check (scripts/check-version-sync.py).

If any errors are reported from skill validation: stop. Report the list of errors to the user. Do not proceed until they are resolved.

Warnings must be reviewed; fix any that relate to skills being changed in this branch.

If version sync fails: stop. Report which files differ and what their versions are. Do not proceed.

Step 2 — Security Scan

Run /security-auditor. If any Critical or High finding remains open after the scan: stop. Report the findings to the user. Do not proceed.

Step 3 — Documentation Accuracy

Run /doc-auditor. If any Critical finding remains open: stop. Report the findings. High findings (missing API/boundary docs) must also be resolved before proceeding. Medium and below may be deferred but must be tracked in docs/audit/doc-findings.md.

Step 4 — Architecture Integrity

If docs/audit/arch-profile.md does not exist or is stale for the current branch, run /arch-detector first to refresh it. Determine staleness from Git metadata, not filesystem mtime (which git checkouts do not preserve): the profile is stale when the most recent commit touching it (git log -1 --format=%ct -- docs/audit/arch-profile.md) is older than the branch's oldest commit (git log --format=%ct main..HEAD | tail -1), or — if git has no record of the file — when the Generated: date inside it predates that commit. Then run /arch-auditor. If any Critical or High finding remains open: stop. Report the findings. Do not proceed.

Step 5 — Exhaustive Code Review

Run /nitpicker in release-gate mode (threshold: High). If any Critical or High finding remains open after fixes are applied: stop. Report the findings. Do not proceed.

Step 6 — Enforcement Surface Loopholes

Run /loophole-hunter. This audits the repository's own Claude Code enforcement surface (.claude/rules/, hook scripts, .claude/settings.json wiring, permissions, and every SKILL.md) for bypassable or unenforced constraints. If any Critical or High finding remains open after fixes are applied: stop. Report the findings. Do not proceed.

Step 7 — Hook Coverage

Run /hooks-enforcer. This audits hook coverage against the repository's evidence base (current hook wiring, the docs/audit/*-findings.md history, git history, and project memory) for recurring failures no hook guards and context-discipline gaps where large-output work bypasses a context-saving tool. If any Critical or High finding remains open after fixes are applied: stop. Report the findings. Do not proceed.

Step 8 — Verify Conventional Commits

Confirm every commit on this branch follows the conventional commits format that release-please uses to determine the version bump and generate release notes:

• feat: — new feature (minor bump)
• fix: — bug fix (patch bump)
• feat!: or BREAKING CHANGE: footer — breaking change (major bump)
• chore:, docs:, refactor: — no version bump

Check the commit log with:

git log main..HEAD --oneline

If any commit message does not follow conventional commits format: stop. Instruct the user to fix all non-conforming messages using:

git rebase -i main
# Mark each bad commit as 'reword' to rename it.

Do not proceed until all commit messages are valid — release-please generates CHANGELOG.md and the version bump automatically from these messages when the PR merges to main.

Do not require or check for a manually-written CHANGELOG.md entry; release-please manages the changelog.

Step 9 — Confirm CI Is Green

Check .github/workflows/validate-skills.yml passed on the current commit. If CI is failing: stop. Report which checks failed. Do not proceed.

Gate Summary

After all steps pass, present this summary to the user:

✅ All release gates passed.

Steps completed:
  [✓] validate-skills — no skill errors; all 5 version files in sync at vX.Y.Z
  [✓] security-auditor — no Critical/High findings
  [✓] doc-auditor — no Critical/High findings
  [✓] arch-auditor — no Critical/High findings
  [✓] nitpicker release-gate — no Critical/High findings
  [✓] loophole-hunter — no Critical/High enforcement-surface findings
  [✓] hooks-enforcer — no Critical/High hook-coverage findings
  [✓] conventional commits — all commits on branch use valid format
  [✓] CI — validate-skills.yml passing

Release-please automation will create the Release PR when these changes are merged
to main. No manual version bump or tagging is needed.

Then ask:

Create a PR for these changes? (y/n) [default: n]

If the user answers n or gives no answer: stop. Inform the user that no PR was created and the branch is ready whenever they choose to open one.

If the user answers y: open a PR using the conventional commit messages on the branch to populate the title and description. Do not bump versions, create tags, or push commits beyond what is already staged.

What This Skill Does NOT Do

• Does not bump version numbers (release-please reads conventional commits and bumps

automatically when the release PR is merged)

• Does not create git tags (release-please creates the tag when the Release PR merges)
• Does not push commits or tags
• Does not create a GitHub Release (release-please creates it after the tag)