pixelheros/CCGS Skill Testing Framework/skills/team/team-release.md

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.