48 coordinated Claude Code subagents for indie game development: - 3 leadership agents (creative-director, technical-director, producer) - 10 department leads (game-designer, lead-programmer, art-director, etc.) - 23 specialist agents (gameplay, engine, AI, networking, UI, tools, etc.) - 12 engine-specific agents (Godot, Unity, Unreal with sub-specialists) Infrastructure: - 34 skills (slash commands) for workflows, reviews, and team orchestration - 8 hooks for commit validation, asset checks, session management - 11 path-scoped rules enforcing domain-specific standards - 28 templates for design docs, reports, and collaborative protocols Key features: - User-driven collaboration protocol (Question → Options → Decision → Draft → Approval) - Engine version awareness with knowledge-gap detection (Godot 4.6 pinned) - Phase gate system for development milestone validation - CLAUDE.md kept under 80 lines with extracted doc imports Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2.9 KiB
name, description, argument-hint, user-invocable, allowed-tools
| name | description | argument-hint | user-invocable | allowed-tools |
|---|---|---|---|---|
| hotfix | Emergency fix workflow that bypasses normal sprint processes with a full audit trail. Creates hotfix branch, tracks approvals, and ensures the fix is backported correctly. | [bug-id or description] | true | Read, Glob, Grep, Write, Edit, Bash |
When this skill is invoked:
Explicit invocation only: This skill should only run when the user explicitly requests it with
/hotfix. Do not auto-invoke based on context matching.
-
Assess the emergency — Read the bug description or ID. Determine severity:
- S1 (Critical): Game unplayable, data loss, security vulnerability — hotfix immediately
- S2 (Major): Significant feature broken, workaround exists — hotfix within 24 hours
- If severity is S3 or lower, recommend using the normal bug fix workflow instead
-
Create the hotfix record at
production/hotfixes/hotfix-[date]-[short-name].md:## Hotfix: [Short Description] Date: [Date] Severity: [S1/S2] Reporter: [Who found it] Status: IN PROGRESS ### Problem [Clear description of what is broken and the player impact] ### Root Cause [To be filled during investigation] ### Fix [To be filled during implementation] ### Testing [What was tested and how] ### Approvals - [ ] Fix reviewed by lead-programmer - [ ] Regression test passed (qa-tester) - [ ] Release approved (producer) ### Rollback Plan [How to revert if the fix causes new issues] -
Create the hotfix branch (if git is initialized):
git checkout -b hotfix/[short-name] [release-tag-or-main] -
Investigate and implement the fix — Focus on the minimal change that resolves the issue. Do NOT refactor, clean up, or add features alongside the hotfix.
-
Validate the fix — Run targeted tests for the affected system. Check for regressions in adjacent systems.
-
Update the hotfix record with root cause, fix details, and test results.
6b. Collect approvals — Use the Task tool to request sign-off:
subagent_type: lead-programmer— Review the fix for correctness and side effectssubagent_type: qa-tester— Run targeted regression tests on the affected systemsubagent_type: producer— Approve deployment timing and communication plan
- Output a summary with: severity, root cause, fix applied, testing status, and what approvals are still needed before deployment.
Rules
- Hotfixes must be the MINIMUM change to fix the issue — no cleanup, no refactoring, no "while we're here" changes
- Every hotfix must have a rollback plan documented before deployment
- Hotfix branches merge to BOTH the release branch AND the development branch
- All hotfixes require a post-incident review within 48 hours
- If the fix is complex enough to need more than 4 hours, escalate to technical-director for a scope decision