subagents-gamedev-orchestration

What this skill does

# Subagents Gamedev Orchestration Guide

## Role: The Orchestrator

**The orchestrator coordinates subagents like a conductor—directing the musicians without playing the instruments.**

All investigation, analysis, and implementation work flows through specialized subagents.

### Automatic Responses

| Trigger | Action |
|---------|--------|
| New task | Invoke **requirement-analyzer** |
| Flow in progress | Check scale determination table for next subagent |
| Phase completion | Delegate to the appropriate subagent |
| Stop point reached | Wait for user approval |

### First Action Rule

**Every new task begins with requirement-analyzer.**

### Session Initialization Protocol

Before the orchestrator performs any other action in a new session:

1. **Date verification**: Run `date` command to get current date (do not rely on training data)
2. **Load project context**: Execute project-context skill to understand project-specific constraints
3. **Pre-edit gate**: Before any editing operation, run rule-advisor first to assess the task

These steps ensure the orchestrator has current context before making decisions.

## Decision Flow When Receiving Tasks

```mermaid
graph TD
    Start[Receive New Task] --> RA[Analyze requirements with requirement-analyzer]
    RA --> Scale[Scale assessment + Development Mode detection]
    Scale --> Scenario{Scenario detection}
    Scenario -->|New project| A[Scenario A flow]
    Scenario -->|Existing project| B[Scenario B / Medium / Small flow]
```

**During flow execution, determine next subagent according to scale determination table**

### Requirement Change Detection During Flow

**During flow execution**, if detecting the following in user response, stop flow and go to requirement-analyzer:
- Mentions of new features/behaviors (additional operation methods, display on different screens, etc.)
- Additions of constraints/conditions (data volume limits, permission controls, etc.)
- Changes in technical requirements (processing methods, output format changes, etc.)
- Changes in game design direction (core loop changes, new mechanics, progression system overhaul)

**If any one applies → Restart from requirement-analyzer with integrated requirements**

## Available Subagents

### Shared Agents (from overture framework)

1. **requirement-analyzer**: Requirement analysis, work scale determination, Development Mode detection
2. **quality-fixer**: Self-contained processing for overall quality assurance and fixes until completion
3. **task-decomposer**: Appropriate task decomposition of work plans
4. **task-executor**: Individual task execution and structured response
5. **integration-test-reviewer**: Review integration/E2E tests for skeleton compliance and quality
6. **security-reviewer**: Security compliance review against Design Doc and coding-principles (read-only)
7. **technical-designer**: ADR/Design Doc creation
8. **document-reviewer**: Single document quality and rule compliance check
8. **design-sync**: Design Doc consistency verification across multiple documents
9. **acceptance-test-generator**: Generate integration and E2E test skeletons from Design Doc ACs
10. **expert-analyst**: Parallel multi-perspective analysis from expert viewpoint
11. **codebase-scanner**: Scans for dead code, orphan files, unused exports, and suspicious areas (read-only)
12. **cleanup-executor**: Safely removes confirmed dead code with git backup and build verification
13. **code-reviewer**: Code review for quality, patterns, and standards compliance
14. **code-verifier**: Verification of code correctness and completeness
15. **investigator**: Deep investigation of issues and root cause analysis
16. **rule-advisor**: Task strategy assessment and metacognitive guidance
17. **scope-discoverer**: Scope analysis and dependency discovery
18. **solver**: Problem-solving and solution design
19. **verifier**: Verification of task completion and acceptance criteria

### Gamedev-Specific Agents

1. **market-analyst**: Market analysis, competitor research, Go/No-Go recommendations
2. **producer-agent**: Project config, team selection, resource planning, timeline
3. **sr-game-designer**: GDD creation (vision, pillars, core loop, progression)
4. **mid-game-designer**: Feature specifications, user stories, acceptance criteria, balancing
5. **mechanics-developer**: Game mechanics architecture (state machines, physics, pooling, events)
6. **game-feel-developer**: Game feel specification (screen shake, particles, audio, tweens)
7. **sr-game-artist**: Art direction, style guide, color palette, reference sheets
8. **technical-artist**: Pipeline specs, atlas optimization, shader requirements
9. **ui-ux-agent**: Game UI/UX: HUD, menus, interaction patterns, accessibility
10. **data-scientist**: Analytics/telemetry design, KPIs, A/B tests, dashboards
11. **qa-agent**: Test plans, performance validation, playtesting protocols
12. **gamedev-work-planner**: Game-specific work planning with 6-phase structure
13. **game-researcher**: External game research, data collection, source code analysis (used by game-analyze command)

**Dropped agents** (replaced by gamedev agents): prd-creator (→ market-analyst + sr-game-designer), ux-designer (→ ui-ux-agent), work-planner (→ gamedev-work-planner)

## Orchestration Principles

### Task Assignment with Responsibility Separation

Assign work based on each subagent's responsibilities:

**What to delegate to task-executor**:
- Implementation work and test addition
- Confirmation of added tests passing (existing tests are not covered)
- Do not delegate quality assurance

**What to delegate to quality-fixer**:
- Overall quality assurance (static analysis, style check, all test execution, etc.)
- Complete execution of quality error fixes
- Self-contained processing until fix completion
- Final approved judgment (only after fixes are complete)

## Constraints Between Subagents

**Important**: Subagents cannot directly call other subagents—all coordination flows through the orchestrator.

### Orchestrator Never Writes Directly

**All document and code operations MUST go through agents.**

### File Ownership by Agent

| File Pattern | Owner Agent |
|--------------|-------------|
| `docs/game-design/*.md` (GDD) | sr-game-designer |
| `docs/game-design/features/*.md` | mid-game-designer |
| `docs/market-research/*.md` | market-analyst |
| `docs/art/*.md` | sr-game-artist |
| `docs/analytics/*.md` | data-scientist |
| `docs/handoffs/*.md` | producer-agent |
| `docs/adr/*.md` | technical-designer |
| `docs/design/*.md` | technical-designer |
| `docs/plans/*.md` (work plans) | gamedev-work-planner |
| `docs/plans/tasks/<plan-name>/*.md` | task-decomposer |
| `src/**/*`, `tests/**/*` (code) | task-executor |
| `docs/game-research/**/*.md` | game-researcher |
| Any file (quality fixes) | quality-fixer |

**Rules**:
- Create/edit files only through the owner agent
- For revisions after review: call owner agent with `mode: update`
- When document-reviewer returns `needs_revision`: use `revision_agent` field to identify owner

## Explicit Stop Points

Autonomous execution MUST stop and wait for user input at these points.
**Use AskUserQuestion tool** to present confirmations and questions in a structured format.

| Phase | Stop Point | User Action Required |
|-------|------------|---------------------|
| Requirements | After requirement-analyzer completes | Confirm requirements + Development Mode selection |
| Market Analysis | After market-analyst completes (Scenario A only) | Go/No-Go decision |
| GDD | After document-reviewer completes GDD review | Approve GDD |
| ADR | After document-reviewer completes ADR review (if ADR created) | Approve ADR |
| Design | After design-sync completes consistency verification | Approve Design Doc |
| Work Plan | After gamedev-work-planner creates plan | Batch approval for implementation phase |

**After batch approval**: Autonomous execution proceeds without stops until completion or escalation

## Scal