pre-release-verification ยท diff
git:20260502.052851b to git:20260606.3b3bb9d
81 added, 11 removed. Audit A to A.
---
name: pre-release-verification
- description: "Use before tagging a release or deploying to production to ensure all quality gates have passed."
+ description: Use when a release candidate needs final checks before tagging, publishing, or production deployment.
---
- # Pre-Release Verification
+ ## Purpose
- Releases must be deterministic and verified. No "hope driven" deployments.
+ Block releases until the repository state, CI status, local validation, and publish metadata are known and reproducible.
- ## Verification Checklist
+ ## When to Use
- Before authorizing or participating in a release process, verify the following:
+ - Before creating a release tag.
+ - Before deploying to production.
+ - Before approving a release candidate prepared by another agent.
+ - When CI is green but local package or catalog checks still need proof.
- 1. **Clean Working Tree**: `git status` must be completely clean. No untracked files or uncommitted changes.
- 2. **Green CI**: The latest commit on the main branch MUST have a passing CI pipeline.
- 3. **Lint & Types**: Run the project's linter (`npm run lint`, `cargo clippy`, etc.) and type checker (`tsc --noEmit`). They must exit with 0.
- 4. **Test Gate**: Run the full test suite locally if CI is not available or if requested.
- 5. **No Secrets**: Ensure no API keys or credentials have been accidentally hardcoded or staged.
+ Do not use as a substitute for fixing failures. If any gate fails, stop and report the blocker.
- If any check fails, the release is blocked. State the exact failure and stop.
+ ## Inputs
+
+ - Intended version or deployment identifier
+ - Current branch and commit
+ - CI status for the release commit
+ - Project-specific build, lint, test, and packaging commands
+
+ ## Workflow
+
+ 1. Confirm the working tree is clean:
+
+ ```bash
+ git status --short
+ ```
+
+ 2. Confirm the release commit and recent history:
+
+ ```bash
+ git log --oneline --decorate -n 10
+ ```
+
+ 3. Confirm CI is green for the exact commit. For GitHub:
+
+ ```bash
+ gh run list --limit 5
+ gh run view <run-id> --json conclusion,status,headSha,url
+ ```
+
+ 4. Run local validation. Use the project's documented commands, for example:
+
+ ```bash
+ npm run build
+ npm test
+ python scripts/validate-skills.py
+ python scripts/validate-catalog.py
+ ```
+
+ 5. Check for secrets or accidental local files:
+
+ ```bash
+ git diff --stat
+ git status --short
+ ```
+
+ 6. Report go/no-go with exact evidence.
+
+ ## Output
+
+ ```text
+ RELEASE VERIFICATION: go / no-go
+ Commit: <sha>
+ CI: <status and URL>
+ Local checks: <commands and results>
+ Blockers: <none or list>
+ Next action: <tag / deploy / stop>
+ ```
+
+ ## Verification
+
+ - [ ] Working tree was clean or dirty files were reported.
+ - [ ] CI status was tied to the exact release commit.
+ - [ ] Local validation commands exited 0.
+ - [ ] No secrets or accidental local files were included.
+ - [ ] Go/no-go recommendation included evidence, not confidence.
+
+ ## Failure Modes
+
+ - Releasing from an uncommitted or untracked local state.
+ - Checking CI for a different commit than the release candidate.
+ - Treating lint/build success as full test coverage.
+ - Continuing after a failed gate because the release is "small".
+