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 Level

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-level [level name or area] [--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

level-designer
narrative-director
world-builder
art-director
systems-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

Step 1: Narrative + Visual Direction (narrative-director + world-builder + art-director, parallel)

Delegate all three independent, bounded briefs concurrently and collect every result before parent synthesis.

Delegate to the narrative-director agent to:

Define the narrative purpose of this area (what story beats happen here?)
Identify key characters, dialogue triggers, and lore elements
Specify emotional arc (how should the player feel entering, during, leaving?)

Delegate to the world-builder agent to:

Provide lore context for the area (history, faction presence, ecology)
Define environmental storytelling opportunities
Specify any world rules that affect gameplay in this area

Delegate to the art-director agent to:

Establish visual theme targets for this area — these are INPUTS to layout, not outputs of it
Define the color temperature and lighting mood for this area (how does it differ from adjacent areas?)
Specify shape language direction (angular fortress? organic cave? decayed grandeur?)
Name the primary visual landmarks that will orient the player
Read design/art/art-bible.md if it exists — anchor all direction in the established art bible

The art-director's visual targets from Step 1 must be passed to the level-designer in Step 2 as explicit constraints. Layout decisions happen within the visual direction, not before it.

Gate: Use request_user_input to present all three Step 1 outputs (narrative brief, lore foundation, visual direction targets) and confirm before proceeding to Step 2.

Step 2: Layout and Encounter Design (level-designer)

Delegate to the level-designer agent with the full Step 1 output as context:

Narrative brief (from narrative-director)
Lore foundation (from world-builder)
Visual direction targets (from art-director) — layout must work within these targets, not contradict them

The level-designer should:

Design the spatial layout (critical path, optional paths, secrets) — ensuring primary routes align with the visual landmark targets from Step 1
Define pacing curve (tension peaks, rest areas, exploration zones) — coordinated with the emotional arc from narrative-director
Place encounters with difficulty progression
Design environmental puzzles or navigation challenges
Define points of interest and landmarks for wayfinding — these must match the visual landmarks the art-director specified
Specify entry/exit points and connections to adjacent areas

Adjacent area dependency check: After the layout is produced, check design/levels/ for each adjacent area referenced by the level-designer. If any referenced area's .md file does not exist, surface the gap:

"Level references [area-name] as an adjacent area but design/levels/[area-name].md does not exist."

Use request_user_input with options:

(a) Proceed with a placeholder reference — mark the connection as UNRESOLVED in the level doc and list it in the open cross-level dependencies section of the summary report
(b) Pause and run $team-level [area-name] first to establish that area

Do NOT invent content for the missing adjacent area.

Gate: Use request_user_input to present Step 2 layout (including any unresolved adjacent area dependencies) and confirm before proceeding to Step 3.

Step 3: Systems Integration (systems-designer)

Delegate to the systems-designer agent to:

Specify enemy compositions and encounter formulas
Define loot tables and reward placement
Balance difficulty relative to expected player level/gear
Design any area-specific mechanics or environmental hazards
Specify resource distribution (health pickups, save points, shops)

Gate: Use request_user_input to present Step 3 outputs and confirm before proceeding to Step 4.

Step 4: Production Concepts + Accessibility (art-director + qa-tester, parallel)

Note: The art-director's directional pass (visual theme, color targets, mood) happened in Step 1. This pass is location-specific production concepts — given the finalized layout, what does each specific space look like?

Delegate to the art-director agent with the finalized layout from Step 2:

Produce location-specific concept specs for key spaces (entrance, key encounter zones, landmarks, exits)
Specify which art assets are unique to this area vs. shared from the global pool
Define sight-line and lighting setups per key space (these are now layout-informed, not directional)
Specify VFX needs that are specific to this area's layout (weather volumes, particles, atmospheric effects)
Flag any locations where the layout creates visual direction conflicts with the Step 1 targets — surface these as production risks

Delegate to the qa-tester agent in parallel to:

Review the level layout for navigation clarity (can players orient themselves without relying on color alone?)
Check that critical path signposting uses shape/icon/sound cues in addition to color
Review any puzzle mechanics for cognitive load — flag anything that requires holding more than 3 simultaneous states
Check that key gameplay areas have sufficient contrast for colorblind players
Output: accessibility concerns list with severity (BLOCKING / RECOMMENDED / NICE TO HAVE)

Wait for both agents to return before proceeding.

Gate: Use request_user_input to present both Step 4 results. If the qa-tester returned any BLOCKING concerns, highlight them prominently and offer:

(a) Return to level-designer and art-director to redesign the flagged elements before Step 5
(b) Document as a known accessibility gap and proceed to Step 5 with the concern explicitly logged in the final report

Do NOT proceed to Step 5 without the user acknowledging any BLOCKING accessibility concerns.

Step 5: QA Planning (qa-tester)

Delegate to the qa-tester agent to:

Write test cases for the critical path
Identify boundary and edge cases (sequence breaks, softlocks)
Create a playtest checklist for the area
Define acceptance criteria for level completion

Compile the level design document combining all team outputs into the level design template format.

After all subagent outputs are collected, delegate to level-designer through Codex custom-agent delegation to compile the final document draft:

Pass: all subagent outputs (verbatim), the level brief, game pillars, relevant GDD sections
Ask level-designer to return the compiled draft and intended path design/levels/[level-name].md without writing.
The parent includes that path in the one consolidated complete changeset approval.

Propose design/levels/[level-name].md through the parent changeset gate.
Output a summary with: area overview, encounter count, estimated asset list, narrative beats, any cross-team dependencies or open questions, open cross-level dependencies (adjacent areas referenced but not yet designed, each marked UNRESOLVED), and accessibility concerns with their resolution status.

Changeset Gate

Delegated agents return drafts or read-only evidence to the parent. The parent synthesizes every proposed edit, lists all affected paths and material changes, and requests one complete changeset approval. After approval, implementation stays within that boundary; any expansion pauses for a revised approval.

Next Steps

Run $design-review design/levels/[level-name].md to validate the completed level design doc.
Run $dev-story to implement level content once the design is approved.
Run $qa-plan to generate a QA test plan for this level.

Error Recovery Protocol

If any delegated agent (through Codex custom-agent delegation) returns BLOCKED, errors, or cannot complete:

Surface immediately: Report "[AgentName]: BLOCKED — [reason]" to the user before continuing to dependent phases
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.
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
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

team-level

Files1

SKILL.md.agents/skills/team-level/SKILL.md