release

Release preparation orchestrator for the current branch. It runs your existing pre-deploy gate, sweeps the docs, bumps the version and commits — then stops and reports. It never pushes, opens a PR, merges, tags, or publishes: those are yours to authorize by name.

It does not re-implement checks, and it does not review code. Review is a separate command that must have run first.

Guardrails

• Spawn a worker and explicitly select your tool's mid tier. State the tier on the spawn — do not omit it and rely on a default. An omitted tier inherits the parent's tier, which is not the same thing as the balanced one. Pick the judgment-capable tier that is cheaper and faster than your top reasoning tier. Not the cheapest/fastest tier: on judgment work it measurably degrades (misclassification rates several times higher). Choose by tier, not by a vendor model name copied from this file — names drift, and this command ships to several tools. Fall back to running inline if your tool has no subagent mechanism.
• Escalate, never assume. Anything you cannot decide, cannot verify, or that this spec does not cover → stop and report it to the orchestrator (the main session). Never improvise, never widen scope, never fix a finding you noticed along the way.
• Nothing leaves the machine. No git push, no gh, no npm publish, under any circumstance — not even if every gate is green. You report the sequence; a human authorizes it.

Phase 0 — Preflight (current branch, always)

• Release the branch you are on. No branch argument, no branch creation.
• On main → stop and ask what should be released. main is only ever the merge target; never release it, never commit to it.
• The tree must be clean — do not commit for the user. Run git status --porcelain. Any line at all — modified, staged, or untracked — is a stop: list the paths and say "commit this to the branch, re-run /branch-review, then re-run /release." Committing here would create a commit after the review and so fail Phase 0.5 by its own rule on the very next step; a phase that guarantees the next phase fails is not a phase.
• git fetch origin; the release diff is origin/main...HEAD. Empty → stop, nothing to release.
• Record both version numbers. Read the local version (package.json or this project's equivalent) and, if the project has a publish path, the published one (npm view <pkg> version, or the registry equivalent). Report them side by side. Local ahead of published means a version was cut on a branch and never published — Phase 3 cannot see that gap unless you record it here, and a worker that cannot see it will re-cut a number that already exists.
• Print a one-line plan: branch · commit count · files changed · HEAD SHA · local version → published version.