/pre-release-review

name: pre-release-review
description: Pre-release gate for the monorepo — establishes per-plugin release boundaries (each plugin's last tag → HEAD), audits every changed plugin's CHANGELOG against the actual code diff, and, depending on the objective the operator picks up front, either hands off to the native `/code-review high --fix` for the deep correctness pass or runs an adversarial design review of what shipped (overengineering, alternative designs, downstream-hermit impact) sourced from the PRs, issues, and proposals behind the window. Use this whenever the operator is about to ship and says "pre-release review", "review before I release", "review what's shipping", "audit the release", "check the release window", "is this ready to tag", "is any of this overengineered", "would you design this differently", "design review before release", or asks to sanity-check accumulated unreleased work before `/release` or `/fleet-release`. Runs BEFORE the release, never mutates version/tags. Trigger even when phrased loosely, as long as the intent is a last look before shipping.

Pre-Release Review

The gate you run right before `/release <slug>` or `/fleet-release`. It answers two questions the release skills assume are already true:

1. **What is actually shipping?** — the real per-plugin diff since each plugin's last tag, not what you think you changed. 2. **Do the changelogs tell the truth about it?** — every operator-visible change has a CHANGELOG line, and no line over- or under-states what the code does.

Then, depending on the mode picked in Step 0, it either runs the native `/code-review high --fix` as the deep correctness pass over the release window, or an adversarial design review of what shipped (Step 3D).

This is a **read-only audit** for its own steps — it never bumps a version, writes a changelog, commits, or tags. `/code-review --fix` (step 4) is the one part that mutates the working tree, and only to apply review fixes. Releasing stays the operator's explicit call via `/release`.

Usage

`/pre-release-review [<plugin-slug>...] [<objective>]`

• **No slug** — sweep every plugin under `plugins/*/` that has commits since its own last tag. This is the default and the common case.
• **One or more slugs** — narrow to those plugins (e.g. `/pre-release-review claude-code-hermit hermit-scribe`).
• **Objective** — any trailing free text. It settles the Step 0 mode when it clearly names one ("design review", "run the deep pass too") and otherwise becomes the lens the verdict answers.

Optional precursor: `/release-status` prints the pipeline table (versions, tags, commits-ahead, core-req staleness). This skill does the deep per-plugin diff + changelog audit that the table only summarizes. Run `/release-status` first if you want the one-line overview before committing to the heavier pass.

Step 0 — Pick the mode

Ask once, before any git work, unless the invocation already settles it. One `AskUserQuestion`, three options; "Other" carries a free-text objective:

1. **Readiness audit** (recommended, default) — Steps 1–3. Cheap, read-only. 2. **Audit + deep correctness review** — Steps 1–4. Picking this *is* the authorization for `/code-review high --fix`: multi-agent, minutes, real tokens, and `--fix` edits the working tree. Say so in the option description so the choice is informed; do not ask again later. 3. **Design review** — Steps 1–3, then Step 3D: an adversarial critique of what shipped (overengineering, alternative designs, downstream-hermit impact), sourced from the PRs, issues, and proposals behind the window. Read-only.

A free-text objective on any option does two things: the Verdict answers it ("ready to tag for <objective>", never an unqualified ready), and Step 3 flags anything in the window that does not serve it as scope creep, even when it is correctly documented.

Step 1 — Establish per-plugin release boundaries

There is no single "release boundary" in this repo: every plugin versions and tags independently (`<slug>--vX.Y.Z`, double-dash, including core as `claude-code-hermit--v*`). The single most-recent reachable tag would give the *smallest* window and silently miss unreleased work in a plugin that hasn't tagged in a while. So compute the boundary **per plugin** — this is the same logic as `/release-status` Step 1.

Glob `plugins/*/.claude-plugin/plugin.json`. For each slug (or just the one passed as arg):

# last tag for this plugin (double-dash format, incl. core)
last_tag=$(git tag --list "<slug>--v*" | sort -V | tail -1)

# base = last tag, or the repo's initial commit if the plugin has never been tagged
base=${last_tag:-$(git rev-list --max-parents=0 HEAD | tail -1)}

# commits in the window, scoped to THIS plugin's directory
git rev-list "$base"..HEAD --count -- plugins/<slug>/

• **0 commits → skip the plugin.** Nothing shipping there.
• **No `plugin.json` version or no recognizable tag** → mark `unstructured (skip)` and move on, exactly as `/release-status` does.
• Record for each in-scope plugin: the base tag name, base commit (short SHA), HEAD commit (short SHA), and commit count.

If the tag choice is ever ambiguous (e.g. legacy single-dash `<slug>-v*` tags alongside the double-dash form, or a tag that isn't an ancestor of HEAD), don't guess silently: state the candidates, pick the most defensible one (newest double-dash tag that is reachable from HEAD, `git merge-base --is-ancestor` to confirm), and say why in the report.

**Pick the review base** for Step 4. The `/code-review` handoff takes a single ref range over the whole repo, not a per-plugin path scope, so choose one base that covers every in-scope plugin. The **oldest** in-scope base tag works: its range to HEAD is a superset of every newer plugin's window. If only one plugin is in scope (or a slug was passed), it's just that plugin's base.

# among the in-scope base commits, pick the oldest by commit date -> $review_base
review_base=$(for b in $in_scope_bases;