team-combat

Use when a combat feature needs coordinated design, implementation, integration, and QA validation.

SKILL.md

GitHub
<!-- codex-studio-delegation: governed -->

Resolve every role through ../../../.codex/docs/plugin-agent-delegation.md; do not require a repository-local .codex/agents/ or .codex/agent-packs/ tree. Before default delegation, run python3 ../../../tools/codex_studio/agent_delegation.py resolve --project-root <project-root> --role <role> and use only its returned role contract.

Team Combat

Codex Interaction Contract

  • Ask one decision question per turn and wait for the answer before asking another.
  • Use request_user_input for structured choices when it is available; otherwise ask the same concise question directly.
  • Use Codex custom agents by role and profile when delegation is useful.
  • Treat any approved write as one complete proposed changeset. Before writing, present every target path and material edit together; do not add unlisted files or behavior.
  • A new path, expanded scope, or material change requires a revised complete proposed changeset and fresh approval.

Invocation

Usage: $team-combat [combat feature] [--review full|lean|solo]. If the required objective cannot be inferred safely, ask for that single missing decision and wait; do not delegate yet.

Review Mode

Read .codex/studio.toml as the only persistent review-mode source. Map review_mode = "phase-gated" to lean optional-review depth; mandatory director gates still run. A --review argument applies only to the current run. Use ../../../.codex/docs/director-gates.md and .codex/docs/technical-preferences.md for native gate and engine context.

Team Roster

  • game-designer
  • gameplay-programmer
  • ai-programmer
  • technical-artist
  • sound-designer
  • qa-tester

Delegation Plan

  • Delegate only tasks that are independent and bounded.
  • Name the Codex custom-agent role and the exact artifact or evidence it must return.
  • Team members must not spawn additional agents (agents.max_depth = 1).
  • The parent agent synthesizes all results, resolves overlap, and communicates with the user.
  • No subagent commits, publishes, or expands scope.
  • Parallel delegation is read-only or draft-only until the parent presents a consolidated result.
  • Any multi-file implementation requires one complete changeset approval before work begins.
  • If a delegated task blocks, surface the evidence and stop dependent work while preserving independent results.

Pipeline

Every phase before ## Parent Changeset Gate is read-only or draft-only. Phase 1 returns a design draft and no agent writes files or implementation.

Phase 1: Design

Delegate to game-designer:

  • Create or update the design document in design/gdd/ covering: mechanic overview, player fantasy, detailed rules, formulas with variable definitions, edge cases, dependencies, tuning knobs with safe ranges, and acceptance criteria
  • Output: completed design-document draft

Phase 2: Architecture

Delegate to gameplay-programmer (with ai-programmer if AI is involved):

  • Review the design document
  • Design the code architecture: class structure, interfaces, data flow
  • Identify integration points with existing systems
  • Output: architecture sketch with file list and interface definitions

Then have technical-artist read the configured engine guidance in .codex/docs/technical-preferences.md and validate the proposed architecture:

  • Is the class/node/component structure idiomatic for the pinned engine? (e.g., Godot node hierarchy, Unity MonoBehaviour vs DOTS, Unreal Actor/Component design)
  • Are there engine-native systems that should be used instead of custom implementations?
  • Any proposed APIs that are deprecated or changed in the pinned engine version?
  • Output: engine architecture notes — incorporate into the architecture before Phase 3 begins

Use request_user_input:

  • Prompt: "Architecture sketch complete. Continue to the parent changeset gate?"
  • Options:
    • [A] Continue — prepare the consolidated changeset
    • [B] Revise the architecture first — I'll describe what needs to change
    • [C] Stop here — I'll continue later

If [A], continue to the parent gate without writing or implementing. If [B] or [C], revise or stop.

Parent Changeset Gate

The parent synthesizes the design and architecture drafts before any mutation. Present one complete proposal containing exact file paths, exact diffs, tests and evidence, and all session-state, report, and milestone writes (use None where no such write exists). Obtain approval for the whole changeset; a new path or material change requires a revised proposal.

Approved Execution

Only after approval may the parent execute or delegate the exact approved changes. No subagent commits, publishes, or expands scope. Every delegate receives only its approved paths, diffs, tests, and acceptance criteria.

Phase 3: Implementation (parallel where possible)

Delegate in parallel:

  • gameplay-programmer: Implement core combat mechanic code
  • ai-programmer: Implement AI behaviors (if the feature involves NPC reactions)
  • technical-artist: Create VFX and shader effects
  • sound-designer: Define audio event list and mixing notes

Phase 4: Integration

  • Wire together gameplay code, AI, VFX, and audio
  • Ensure all tuning knobs are exposed and data-driven
  • Verify the feature works with existing combat systems

Phase 5: Validation

Delegate to qa-tester:

  • Write test cases from the acceptance criteria
  • Test all edge cases documented in the design
  • Verify performance impact is within budget
  • File bug reports for any issues found

Phase 6: Sign-off

  • Collect results from all team members
  • Report feature status: COMPLETE / NEEDS WORK / BLOCKED
  • List any outstanding issues and their assigned owners

Error Recovery Protocol

If any delegated agent (through Codex custom-agent delegation) 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 request_user_input 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: design completion status, implementation status per team member, test results, and any open issues.

Verdict: COMPLETE — combat feature designed, implemented, and validated. Verdict: BLOCKED — one or more phases could not complete; partial report produced with unresolved items listed.

Next Steps

  • Run $code-review on the implemented combat code before closing stories.
  • Run $balance-check to validate combat formulas and tuning values.
  • Run $team-polish if VFX, audio, or performance polish is needed.