mirror of
https://github.com/Donchitos/Claude-Code-Game-Studios.git
synced 2026-06-27 04:51:46 +00:00
f36494e70c
Model tier assignment: - model: haiku → help, sprint-status, story-readiness, scope-check, project-stage-detect, changelog, patch-notes, onboard (read-only/format) - model: opus → review-all-gdds, architecture-review, gate-check (multi-doc synthesis, high-stakes verdicts) PostCompact hook: - New .claude/hooks/post-compact.sh — fires after compaction, reminds Claude to re-read production/session-state/active.md to restore context - Registered in settings.json between PreCompact and Stop Parallel Task spawning: - review-all-gdds: Phase 2 (consistency) and Phase 3 (design theory) now explicitly instructed to spawn as parallel Task agents simultaneously Error Recovery Protocol: - Standard BLOCKED-handling section added to: review-all-gdds, architecture-review, dev-story, team-combat, team-qa, team-narrative, team-level, team-ui, team-audio, team-release, team-polish - Pattern: surface blocker → assess dependencies → offer 3 options via AskUserQuestion → always produce partial report Coordination rules: - Added Model Tier Assignment table with routing rationale - Added Subagents vs Agent Teams section (experimental agent teams docs) - Added Parallel Task Protocol (when/how to spawn parallel agents) Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
118 lines
6.7 KiB
Markdown
118 lines
6.7 KiB
Markdown
---
|
|
name: team-release
|
|
description: "Orchestrate the release team: coordinates release-manager, qa-lead, devops-engineer, and producer to execute a release from candidate to deployment."
|
|
argument-hint: "[version number or 'next']"
|
|
user-invocable: true
|
|
allowed-tools: Read, Glob, Grep, Write, Edit, Bash, Task, AskUserQuestion, TodoWrite
|
|
---
|
|
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.
|
|
The user must approve before moving to the next phase.
|
|
|
|
## Team Composition
|
|
- **release-manager** — Release branch, versioning, changelog, deployment
|
|
- **qa-lead** — Test sign-off, regression suite, release quality gate
|
|
- **devops-engineer** — Build pipeline, artifacts, deployment automation
|
|
- **security-engineer** — Pre-release security audit (invoke if game has online/multiplayer features or player data)
|
|
- **analytics-engineer** — Verify telemetry events fire correctly and dashboards are live
|
|
- **community-manager** — Patch notes, launch announcement, player-facing messaging
|
|
- **producer** — Go/no-go decision, stakeholder communication, scheduling
|
|
|
|
## How to Delegate
|
|
|
|
Use the Task tool to spawn each team member as a subagent:
|
|
- `subagent_type: release-manager` — Release branch, versioning, changelog, deployment
|
|
- `subagent_type: qa-lead` — Test sign-off, regression suite, release quality gate
|
|
- `subagent_type: devops-engineer` — Build pipeline, artifacts, deployment automation
|
|
- `subagent_type: security-engineer` — Security audit for online/multiplayer/data features
|
|
- `subagent_type: analytics-engineer` — Telemetry event verification and dashboard readiness
|
|
- `subagent_type: community-manager` — Patch notes and launch communication
|
|
- `subagent_type: producer` — Go/no-go decision, stakeholder communication
|
|
- `subagent_type: network-programmer` — Netcode stability sign-off (invoke if game has multiplayer)
|
|
|
|
Always provide full context in each agent's prompt (version number, milestone status, known issues). Launch independent agents in parallel where the pipeline allows it (e.g., Phase 3 agents can run simultaneously).
|
|
|
|
## Pipeline
|
|
|
|
### Phase 1: Release Planning
|
|
Delegate to **producer**:
|
|
- Confirm all milestone acceptance criteria are met
|
|
- Identify any scope items deferred from this release
|
|
- Set the target release date and communicate to team
|
|
- Output: release authorization with scope confirmation
|
|
|
|
### Phase 2: Release Candidate
|
|
Delegate to **release-manager**:
|
|
- Cut release branch from the agreed commit
|
|
- Bump version numbers in all relevant files
|
|
- Generate the release checklist using `/release-checklist`
|
|
- Freeze the branch — no feature changes, bug fixes only
|
|
- Output: release branch name and checklist
|
|
|
|
### Phase 3: Quality Gate (parallel)
|
|
Delegate in parallel:
|
|
- **qa-lead**: Execute full regression test suite. Test all critical paths. Verify no S1/S2 bugs. Sign off on quality.
|
|
- **devops-engineer**: Build release artifacts for all target platforms. Verify builds are clean and reproducible. Run automated tests in CI.
|
|
- **security-engineer** *(if game has online features, multiplayer, or player data)*: Conduct pre-release security audit. Review authentication, anti-cheat, data privacy compliance. Sign off on security posture.
|
|
- **network-programmer** *(if game has multiplayer)*: Sign off on netcode stability. Verify lag compensation, reconnect handling, and bandwidth usage under load.
|
|
|
|
### Phase 4: Localization, Performance, and Analytics
|
|
Delegate (can run in parallel with Phase 3 if resources available):
|
|
- Verify all strings are translated (delegate to **localization-lead** if available)
|
|
- Run performance benchmarks against targets (delegate to **performance-analyst** if available)
|
|
- **analytics-engineer**: Verify all telemetry events fire correctly on release build. Confirm dashboards are receiving data. Check that critical funnels (onboarding, progression, monetization if applicable) are instrumented.
|
|
- Output: localization, performance, and analytics sign-off
|
|
|
|
### Phase 5: Go/No-Go
|
|
Delegate to **producer**:
|
|
- Collect sign-off from: qa-lead, release-manager, devops-engineer, technical-director
|
|
- Evaluate any open issues — are they blocking or can they ship?
|
|
- Make the go/no-go call
|
|
- Output: release decision with rationale
|
|
|
|
### Phase 6: Deployment (if GO)
|
|
Delegate to **release-manager** + **devops-engineer**:
|
|
- Tag the release in version control
|
|
- Generate changelog using `/changelog`
|
|
- Deploy to staging for final smoke test
|
|
- Deploy to production
|
|
- Monitor for 48 hours post-release
|
|
|
|
Delegate to **community-manager** (in parallel with deployment):
|
|
- Finalize patch notes using `/patch-notes [version]`
|
|
- Prepare launch announcement (store page updates, social media, community post)
|
|
- Draft known issues post if any S3+ issues shipped
|
|
- Output: all player-facing release communication, ready to publish on deploy confirmation
|
|
|
|
### Phase 7: Post-Release
|
|
- **release-manager**: Generate release report (what shipped, what was deferred, metrics)
|
|
- **producer**: Update milestone tracking, communicate to stakeholders
|
|
- **qa-lead**: Monitor incoming bug reports for regressions
|
|
- **community-manager**: Publish all player-facing communication, monitor community sentiment
|
|
- **analytics-engineer**: Confirm live dashboards are healthy; alert if any critical events are missing
|
|
- Schedule post-release retrospective if issues occurred
|
|
|
|
## Error Recovery Protocol
|
|
|
|
If any spawned agent (via Task) returns BLOCKED, errors, or cannot complete:
|
|
|
|
1. **Surface immediately**: Report "[AgentName]: BLOCKED — [reason]" to the user before continuing to dependent phases
|
|
2. **Assess dependencies**: Check whether the blocked agent's output is required by subsequent phases. If yes, do not proceed past that dependency point without user input.
|
|
3. **Offer options** via AskUserQuestion with choices:
|
|
- Skip this agent and note the gap in the final report
|
|
- Retry with narrower scope
|
|
- Stop here and resolve the blocker first
|
|
4. **Always produce a partial report** — output whatever was completed. Never discard work because one agent blocked.
|
|
|
|
Common blockers:
|
|
- Input file missing (story not found, GDD absent) → redirect to the skill that creates it
|
|
- ADR status is Proposed → do not implement; run `/architecture-decision` first
|
|
- Scope too large → split into two stories via `/create-stories`
|
|
- Conflicting instructions between ADR and story → surface the conflict, do not guess
|
|
|
|
## Output
|
|
A summary report covering: release version, scope, quality gate results, go/no-go decision, deployment status, and monitoring plan.
|