216 lines
15 KiB
Markdown
216 lines
15 KiB
Markdown
# 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.
|