# Skill Test Spec: /team-release ## Skill Summary Orchestrates the release team through a 7-phase pipeline from release candidate to deployment and post-release monitoring. Coordinates release-manager, qa-lead, devops-engineer, producer, security-engineer (optional, required for online/ multiplayer), network-programmer (optional, required for multiplayer), analytics-engineer, and community-manager. Phase 3 agents run in parallel. Ends with a go/no-go decision; deployment (Phase 6) is skipped if the producer calls NO-GO. Closes with a post-release monitoring plan. --- ## Static Assertions (Structural) - [ ] Has required frontmatter fields: `name`, `description`, `argument-hint`, `user-invocable`, `allowed-tools` - [ ] Has ≥2 phase headings - [ ] Contains verdict keywords: COMPLETE, BLOCKED - [ ] Contains "May I write" language in the File Write Protocol section (delegated to sub-agents) - [ ] Has a File Write Protocol section stating that the orchestrator does not write files directly - [ ] Has an Error Recovery Protocol section with four recovery options (surface / assess / offer options / partial report) - [ ] Has a next-step handoff referencing post-release monitoring, `/retrospective`, and `production/stage.txt` - [ ] Uses `AskUserQuestion` at phase transitions requiring user approval before proceeding - [ ] Phase 3 agents (qa-lead, devops-engineer, and optionally security-engineer, network-programmer) are explicitly stated to run in parallel - [ ] Phase 6 (Deployment) is conditional on a GO decision from Phase 5 - [ ] security-engineer is described as conditional on online features / player data — not always spawned --- ## Test Cases ### Case 1: Happy Path (Single-Player) — All phases complete, version deployed **Fixture:** - `production/stage.txt` exists and contains a Production-or-later stage - Milestone acceptance criteria are all met (producer can confirm) - No online features, no multiplayer, no player data collection - All CI builds are clean on the current branch - No open S1/S2 bugs - `production/sprints/` contains the completed sprint stories for this milestone **Input:** `/team-release v1.0.0` **Expected behavior:** 1. Phase 1: Spawns `producer` via Task; confirms all milestone acceptance criteria met; identifies any deferred scope; produces release authorization; presents to user; AskUserQuestion: user approves before Phase 2 2. Phase 2: Spawns `release-manager` via Task; cuts release branch from agreed commit; bumps version numbers; invokes `/release-checklist`; freezes branch; output: branch name and checklist; AskUserQuestion: user approves before Phase 3 3. Phase 3 (parallel): Issues Task calls simultaneously for `qa-lead` (regression suite, critical path sign-off) and `devops-engineer` (build artifacts, CI verification); security-engineer is NOT spawned (no online features); network-programmer is NOT spawned (no multiplayer); both complete successfully 4. Phase 4: Verifies localization strings all translated; `analytics-engineer` verifies telemetry fires correctly on the release build; performance benchmarks pass; sign-off produced 5. Phase 5: Spawns `producer` via Task; collects sign-offs from qa-lead, release-manager, devops-engineer; no open blocking issues; producer declares GO; AskUserQuestion: user sees GO decision and confirms deployment 6. Phase 6: Spawns `release-manager` + `devops-engineer` (parallel); tags release in version control; invokes `/changelog`; deploys to staging; smoke test passes; deploys to production; simultaneously spawns `community-manager` to finalize patch notes via `/patch-notes v1.0.0` and prepare launch announcement 7. Phase 7: release-manager generates release report; producer updates milestone tracking; qa-lead begins monitoring for regressions; community-manager publishes communication; analytics-engineer confirms live dashboards healthy 8. Verdict: COMPLETE — release executed and deployed **Assertions:** - [ ] Phase 3 qa-lead and devops-engineer Task calls are issued simultaneously, not sequentially - [ ] security-engineer is NOT spawned when the game has no online features, multiplayer, or player data - [ ] Phase 5 producer collects sign-offs from all required parties before declaring GO - [ ] Phase 6 deployment only begins after GO decision is confirmed by the user - [ ] `/changelog` is invoked by release-manager in Phase 6 (not written directly) - [ ] `/patch-notes v1.0.0` is invoked by community-manager in Phase 6 - [ ] Phase 7 monitoring plan includes a 48-hour post-release monitoring commitment - [ ] Next steps recommend updating `production/stage.txt` to `Live` after successful deployment - [ ] Verdict: COMPLETE appears in the final output --- ### Case 2: Go/No-Go: NO — S1 bug found in Phase 3, deployment skipped **Fixture:** - Release candidate branch exists for v0.9.0 - qa-lead discovers a previously unreported S1 crash in the main menu during Phase 3 regression testing - devops-engineer build is clean and artifacts are ready - producer is aware of the S1 bug **Input:** `/team-release v0.9.0` **Expected behavior:** 1. Phases 1–2 complete normally; release candidate is cut 2. Phase 3 (parallel): devops-engineer returns clean build sign-off; qa-lead returns with an S1 bug identified and regression suite failing; qa-lead declares quality gate: NOT PASSED 3. Orchestrator surfaces the qa-lead result immediately: "QA-LEAD: S1 bug found — [crash description]. Quality gate: NOT PASSED." 4. Phase 4 proceeds cautiously or is paused (AskUserQuestion: continue to Phase 4 or skip to Phase 5 for go/no-go?) 5. Phase 5: Spawns `producer` via Task; producer receives qa-lead's NOT PASSED verdict; no S1 sign-off available; producer declares NO-GO with rationale: "S1 bug [ID] is open and unresolved. Releasing is not safe." 6. AskUserQuestion: user is presented with the NO-GO decision and the S1 bug details; options: fix the bug and re-run, defer the release, or override (with documented rationale) 7. Phase 6 (Deployment) is SKIPPED entirely — no branch tagging, no deploy to staging, no deploy to production 8. community-manager is NOT spawned in Phase 6 (no deployment to announce) 9. Skill ends with a partial report summarizing what was completed (Phases 1–5) and what was skipped (Phase 6) and why 10. Verdict: BLOCKED — release not deployed **Assertions:** - [ ] qa-lead S1 bug finding is surfaced to the user immediately after Phase 3 completes — not suppressed until Phase 5 - [ ] producer's NO-GO decision explicitly references the S1 bug and the quality gate result - [ ] Phase 6 Deployment is completely skipped when producer declares NO-GO - [ ] community-manager is NOT spawned for patch notes or launch announcement on NO-GO - [ ] The partial report clearly states which phases completed and which were skipped, with reasons - [ ] Verdict: BLOCKED (not COMPLETE) when deployment is skipped due to NO-GO - [ ] AskUserQuestion offers the user resolution options (fix and re-run / defer / override with rationale) - [ ] Override path (if chosen) requires user to provide a documented rationale before proceeding to Phase 6 --- ### Case 3: Security Audit for Online Game — security-engineer is spawned in Phase 3 **Fixture:** - Game has multiplayer features and stores player account data - Release candidate exists for v2.1.0 - qa-lead and devops-engineer both return clean sign-offs - security-engineer audit is required per team composition rules **Input:** `/team-release v2.1.0` **Expected behavior:** 1. Phases 1–2 complete normally 2. Phase 3 (parallel): Orchestrator detects that the game has online/multiplayer features and player data; issues Task calls simultaneously for `qa-lead`, `devops-engineer`, AND `security-engineer`; also spawns `network-programmer` for netcode stability sign-off 3. security-engineer conducts pre-release security audit: reviews authentication flows, anti-cheat presence, data privacy compliance; returns sign-off 4. network-programmer verifies lag compensation, reconnect handling, and bandwidth under load; returns sign-off 5. All four Phase 3 agents complete; their results are collected before Phase 4 begins 6. Phase 5: producer collects sign-offs from all four Phase 3 agents (qa-lead, devops-engineer, security-engineer, network-programmer) before making the go/no-go call 7. Remaining phases proceed normally to COMPLETE **Assertions:** - [ ] security-engineer IS spawned in Phase 3 when the game has online features, multiplayer, or player data — this is not skipped - [ ] network-programmer IS spawned in Phase 3 when the game has multiplayer - [ ] All four Phase 3 Task calls (qa-lead, devops-engineer, security-engineer, network-programmer) are issued simultaneously - [ ] security-engineer audit covers authentication, anti-cheat, and data privacy compliance - [ ] Phase 5 producer sign-off collection includes security-engineer (four parties, not two) - [ ] Phase 6 deployment does not begin until security-engineer has signed off - [ ] Skill does NOT treat security-engineer as optional for a game with player data --- ### Case 4: Localization Miss — Untranslated strings block the ship **Fixture:** - Release candidate exists for v1.2.0 - Phase 3 (qa-lead, devops-engineer) complete with clean sign-offs - Phase 4: localization verification detects 47 untranslated strings in the French locale (a supported language in the game's localization scope) - localization-lead is available as a delegatable agent **Input:** `/team-release v1.2.0` **Expected behavior:** 1. Phases 1–3 complete with clean sign-offs 2. Phase 4: Localization verification step detects untranslated strings; identifies 47 strings in French locale; localization-lead (if available) is spawned to assess the severity 3. Orchestrator surfaces: "LOCALIZATION MISS: 47 untranslated strings found in French locale. Localization sign-off is required before shipping." 4. AskUserQuestion: options presented — (a) Fix translations and re-run Phase 4, (b) Remove French locale from this release, (c) Ship as-is with a known issues note 5. If user selects (a): Phase 4 is re-run after translations are provided; skill waits for localization sign-off 6. Phase 5 go/no-go does NOT proceed while localization sign-off is outstanding 7. Ship is blocked (Phase 6 not entered) until localization issue is resolved or explicitly waived **Assertions:** - [ ] Localization verification in Phase 4 detects untranslated strings and counts them (not just "some strings missing") - [ ] Untranslated strings for a supported locale block the pipeline before Phase 5 - [ ] AskUserQuestion is used to offer the user resolution choices — the skill does not auto-waive - [ ] Phase 5 go/no-go is NOT called while localization sign-off is pending - [ ] If user chooses to re-run Phase 4: the skill does not require restarting from Phase 1 - [ ] If user explicitly waives (ships as-is): the waiver is documented in the release report (Phase 7) as a known issue - [ ] Skill does NOT fabricate translated strings to unblock itself --- ### Case 5: No Argument — Skill infers version or asks **Fixture (variant A — milestone data present):** - `production/milestones/` exists with a milestone file; most recent milestone is "v1.1.0 — Gold" - `production/session-state/active.md` references a version or milestone **Fixture (variant B — no discoverable version):** - `production/milestones/` does not exist - `production/session-state/active.md` does not reference a version - No git tags are present from which to infer a version **Input:** `/team-release` (no argument) **Expected behavior (variant A):** 1. Phase 1: No argument provided; reads `production/session-state/active.md`; reads most recent milestone file in `production/milestones/` 2. Infers v1.1.0 as the target version; reports "No version argument provided — inferred v1.1.0 from milestone data. Proceeding." 3. Confirms with AskUserQuestion before beginning Phase 1 proper: "Releasing v1.1.0. Is this correct?" 4. Proceeds as if `/team-release v1.1.0` was the input **Expected behavior (variant B):** 1. Phase 1: No argument provided; reads available state files — no version discoverable 2. Uses AskUserQuestion: "What version number should be released? (e.g., v1.0.0)" 3. Waits for user input before proceeding **Assertions:** - [ ] Skill does NOT default to a hardcoded version string when no argument is provided - [ ] Skill reads `production/session-state/active.md` and milestone files before asking (variant A) - [ ] Inferred version is confirmed with the user via AskUserQuestion before proceeding (variant A) - [ ] When no version is discoverable, AskUserQuestion is used — skill does not guess (variant B) - [ ] Skill does NOT error out when milestone files are absent — it falls back to asking (variant B) --- ## Protocol Compliance - [ ] `AskUserQuestion` used at each phase transition gate (post-Phase 1, post-Phase 2, post-Phase 3/4 if issues, post-Phase 5 go/no-go) - [ ] Phase 3 agents are always issued as parallel Task calls — qa-lead and devops-engineer are never sequential - [ ] security-engineer is conditionally spawned based on game features — never silently skipped when features are present - [ ] File Write Protocol: orchestrator never calls Write/Edit directly — all writes are delegated to sub-agents or sub-skills - [ ] Phase 6 Deployment is strictly conditional on a GO verdict from Phase 5 — never auto-triggered - [ ] Error recovery: any BLOCKED agent is surfaced immediately before continuing to dependent phases - [ ] Partial reports are always produced if any phase fails or the pipeline is halted (Case 2) - [ ] Verdict: COMPLETE only when deployment completes; BLOCKED when go/no-go is NO or a hard blocker is unresolved - [ ] Next steps always include 48-hour post-release monitoring, `/retrospective` recommendation, and `production/stage.txt` update to `Live` --- ## Coverage Notes - Phase 7 post-release actions (release report, milestone tracking, community publishing, dashboard monitoring) are validated implicitly by Case 1. No separate edge case is required as Phase 7 is non-gated and does not have a blocking failure mode. - The "devops-engineer build fails" path is not separately tested — it would surface as a BLOCKED result in Phase 3 and follow the standard error recovery protocol (surface → assess → AskUserQuestion options). This is validated structurally by the Static Assertions error recovery check. - The parallel Phase 4 path (localization + performance + analytics simultaneously with Phase 3) is a documented option in the skill ("can run in parallel with Phase 3 if resources available"). Case 4 tests Phase 4 as a sequential gate; the parallel variant is left to the skill's implementation judgment. - The `network-programmer` sign-off path for multiplayer is validated as part of Case 3 rather than a separate case, as it follows the same parallel-spawn pattern as security-engineer. - The "override NO-GO with documented rationale" path in Case 2 is referenced but not exhaustively tested — it is an escape hatch that the skill must support, and its existence is validated by the AskUserQuestion options assertion in Case 2.