release-manager

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).