/team-release

name: team-release
description: "Orchestrate the release team — release-manager, qa-lead, devops-engineer, producer — to execute a release from candidate to deployment."
argument-hint: "[version number or 'next'] [--review full|lean|solo]"
user-invocable: true
allowed-tools: Read, Glob, Grep, Write, Edit, Agent, AskUserQuestion, TaskCreate, TaskGet, TaskList, TaskUpdate, Bash(bash "*/.claude/skills/team-release/../../hooks/yaml-helper.sh" resolve_config *)
model: sonnet

Team Release

**Argument check:** If no version number is provided: 1. Read `production/session-state/active.md` and the most recent file in `production/milestones/` (if they exist) to infer the target version. 2. If a version is found: report "No version argument provided — inferred [version] from milestone data. Proceeding." Then confirm with `AskUserQuestion`: "Releasing [version]. Is this correct?" 3. If no version is discoverable: use `AskUserQuestion` to ask "What version number should be released? (e.g., v1.0.0)" and wait for user input before proceeding. Do not default to a hardcoded version string.

When this skill is invoked, orchestrate the release team through a structured pipeline.

**Decision Points:** At each phase transition, use `AskUserQuestion` to present the user with the subagent's proposals as selectable options. Write the agent's full analysis in conversation, then capture the decision with concise labels. In `collaborative` mode, the user must approve before moving to the next phase. In `guided` mode the pipeline advances automatically unless a phase is BLOCKED; in `autonomous` mode it runs end to end, recording each phase outcome via `log_decision`. Decisions in `automation_always_ask` categories (`is_always_ask_category` helper) always prompt regardless of mode. See `.claude/docs/automation-modes.md`.

Phase 0: Resolve Config

!`bash "${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh" resolve_config --keys review_mode,automation,team.size,workflow,project.stage`

Resolved above — use as-is; `--review` overrides `review_mode`. No block → defaults in `.claude/docs/config-resolution.md`.

**Stage check — before anything is spawned.** This skill ships a release, and `/gate-check release` is the readiness gate that must pass first; only its PASS sets `project.stage` to `Release`. If the resolved `project.stage` is anything else — `Polish`, an earlier stage, or not set — stop before Phase 1 and spawn nothing:

> "The release readiness gate has not passed (project.stage: [stage]) — run > `/gate-check release` first."

Then ask with `AskUserQuestion`, in every `automation` mode — an override is never taken on the user's behalf: `[A] Stop — I'll run /gate-check release (recommended)` / `[B] Proceed anyway — override the stage check`. On `[A]`, end the run: Verdict **BLOCKED** — release gate not passed. On `[B]`, ask (plain text) why, then record the override as `Stage override: project.stage was [stage] — release gate not passed; the user chose to proceed: [reason]` in the Phase 1 brief, in the go/no-go record (`go-no-go-[version].md`) and in the final report. An override never changes the stage itself.

`review_mode` sets director-gate depth, and this pipeline has no director gate: no phase below spawns CD-, TD-, PR- or AD-PHASE-GATE, at any `review_mode`. Its phase gates are the pipeline's own decision points (defined under `team.size` below), and the agents that work at them are team members, not director gates.

`automation` drives the Decision Points note above. See the Decision Points note above and `.claude/docs/automation-modes.md` for how each mode changes pipeline behavior.

**`team.size`**: which agents are active (orthogonal to review_mode gate-depth and workflow docs).

• **`individual`** (default): `release-manager` only. Other agents consulted via the release-manager, not spawned separately.
• **`small`**: + `producer` + `devops-engineer` + `qa-lead` + `community-manager`.
• **`studio`**: + `security-engineer` + `analytics-engineer` + `localization-lead` + `performance-analyst`, and `network-programmer` when the game is multiplayer (the full pipeline as documented).

A non-core agent needed at `individual` routes through the nearest active core agent with an informational note. **"Phase gate" means any phase that ends in an `AskUserQuestion` decision point this pipeline itself lists** — a transition under Decision Points above, the stage check, or the Phase 6 deploy question — **whatever the `automation` mode.** `guided` and `autonomous` change how a gate is passed (it auto-advances, or is recorded with `log_decision`), not whether it is one, so bounded-exception condition (3) below holds at it in every mode. An agent restricted to "phase gates only" is spawned at those points and no others. This active-set scoping applies throughout the pipeline below: any phase that names an agent outside the active set routes through the nearest core agent rather than spawning it.

**Announce the active set before Phase 1 — never let the collapse be silent.** Before spawning anything, state in one line which agents this run will actually spawn, and which the pipeline below names but will **not** spawn at the resolved `team.size`. For example:

> `Active set (team.size: <resolved>): <the agents listed for that size above>.` > `Not spawned this run: <every other agent this pipeline names> — consulted` > `through <nearest active core agent>. Raise team.size (or modes.rigor) to widen.`

Fill it from the `team.size` list directly above and the agents this file's own pipeline names — not from an example. Both sets differ per orchestrator.

The pipeline below reads as a multi-agent fan-out and at the shipped default it is one or two agents — `team-release` names ten and runs one, `team-narrative` names six across five phases and runs `writer` alone. **The collapse is correct**: `team.size` is rigor-fronted and the narrow default is the token lever. Without saying so, a reader cannot distinguish a correc