| name | release-manager |
| description | Multi-persona release vetting board — PM, EM, Designer, QA personas deeply analyze the release candidate; produces the signed verdict file WITHOUT which /release refuses to proceed. Use before any release, when asked to vet a release, or when cutting a version. |
| trigger | /release-manager |
/release-manager — the vetting board (no verdict file, no release)
A human release manager doesn't re-run the tests and call it a day — they ask whether
this release should exist, whether it will hurt anyone, and whether the story told
about it is true. This skill runs that judgment as a panel of personas, each in its
OWN agent context (shared context = shared blind spots), then synthesizes a written
go/no-go verdict. /release is mechanically blocked without it.
0. Scope the candidate
Fix the exact release: version, target SHA, changelog range (git log <last-tag>..).
Everything below judges THAT snapshot — a new commit after the verdict voids it.
1. The persona panel (separate agent contexts, run in parallel)
Each persona receives: the changelog range, the diff-stat, the README, and its brief.
Each returns findings + a personal GO / NO-GO with one paragraph of reasoning.
- Product Manager — is this a coherent release a user can understand? Does every
user-visible change appear in the changelog in user language? Does the README/docs
story match what actually ships (install it fresh and follow the quickstart
literally)? Is anything half-shipped that should be held back or flagged
experimental? Would YOU tweet this release?
- Engineering Manager — risk audit: breaking changes vs semver; dependency delta
(new deps justified? security advisories open? Dependabot state?); rollback story
(can a user pin the previous version cleanly?); the flakiest test in the suite;
open P0/launch-blocking issues (an open perf or correctness P0 = NO-GO); CI green
on the exact SHA, not a cousin.
- Designer — render the artifacts fresh and LOOK at them: terminal receipt (both
a priced and an unpriced session), SVG light + dark rasterized, PNG, the README as
GitHub renders it. Any regression in the product's face = NO-GO. Screenshots
attached to the verdict.
- QA / adversarial user — try to break the quickstart in 20 minutes: empty
transcript dir, weird locale, no git, malformed budget.json, huge session, piped
vs TTY stdout. Every crash or wrong number = finding; any I2 violation
(fabricated dollar) = instant NO-GO.
2. Mechanical deep checks (the lead runs these, unmasked)
- Full gate matrix fresh on the release SHA (tsc/eslint/vitest/goldens/determinism
×10/spec-lint/hygiene/cite-check LIVE).
- Packed-tarball smoke:
npm pack → install the tarball into a temp dir →
run the binary against a fixture transcript → assert exit 0 + a rendered receipt.
This is the only test that catches packaging breaks (files whitelist, bin path,
runtime-vs-dev dependencies).
npm publish --dry-run — inspect the file list line by line (no fixtures, no
transcripts, no .env, no internal docs).- gitleaks full-history scan (the pre-flip button) — clean or explained.
/review-docs panel verdict (blocking per the release skill already).
3. The verdict file (the gate)
Write docs/releases/<version>-verdict.md: candidate SHA, per-persona findings and
votes, mechanical-check results, open-risk list, and the final line — exactly
VERDICT: GO or VERDICT: NO-GO (<reason>). Any persona NO-GO that the lead
overrides must carry a written override justification (overrides are visible
forever; use sparingly).
4. Enforcement
/release step 0 mechanically checks that docs/releases/<version>-verdict.md
exists for the exact version being cut, contains VERDICT: GO, and names the same
SHA being tagged. Missing, stale-SHA, or NO-GO → the release stops. No exceptions —
including for the maintainer, including for "tiny" releases (the tiny ones are where
packaging breaks hide).
