Release 1.1.2 — the default path works end to end

Fix release for 1.1.1: the minimal path end to end, engine commands that run on Godot, Unity and Unreal, hook warnings you can see, and verdicts that say when they could not check. Details in CHANGELOG.md; upgrade steps in UPGRADING.md (v1.1.1 → v1.1.2). Fixes #67 Fixes #131 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WuJn2FdynEybfL5KC697nJ
2026-10-16 10:17:06 +00:00 · 2026-09-29 21:32:19 +10:00
parent 7ed2c3e9c4
commit b21fa0f7f2
383 changed files with 22888 additions and 10618 deletions
@@ -6,12 +6,18 @@ Orchestrates the audio team through a four-step pipeline: audio direction
 (audio-director) → sound design + accessibility review in parallel (sound-designer
 + accessibility-specialist) → technical implementation + engine validation in
 parallel (technical-artist + primary engine specialist) → code integration
-(gameplay-programmer). Reads relevant GDDs, the sound bible (if present), and
-existing audio asset lists before spawning agents. Compiles all outputs into an
-audio design document saved to `design/gdd/audio-[feature].md`. Uses
-`AskUserQuestion` at each step transition. Verdict is COMPLETE when the audio
-design document is produced. Skips the engine specialist spawn gracefully when no
-engine is configured.
+(gameplay-programmer). Phase 0 resolves `review_mode`, `automation` and
+`team.size`, and the skill announces the active agent set in one line before
+Step 1 — at the default `team.size: individual` only sound-designer is spawned and
+every other agent is consulted through it. Reads relevant GDDs, the sound bible (if
+present), and existing audio asset lists before spawning agents. Sub-agents write
+their working artifacts to paths the orchestrator names, under the bounded write
+exception; the orchestrator compiles the audio design document itself and writes it
+to `design/audio/audio-[feature].md` only after asking via `AskUserQuestion`. Uses
+`AskUserQuestion` at each step transition. Verdict is COMPLETE when the audio design
+document is produced, BLOCKED when an unresolved dependency stops the pipeline.
+Skips the engine specialist when no engine is configured and records
+`Engine validation: NOT ASSESSED`.

 ---

@@ -21,15 +27,20 @@ engine is configured.
 - [ ] Has ≥2 step/phase headings
 - [ ] Contains verdict keywords: COMPLETE, BLOCKED
 - [ ] Contains "File Write Protocol" section
- [ ] File writes are delegated to sub-agents — orchestrator does not write files directly
- [ ] Sub-agents enforce "May I write to [path]?" before any write
+- [ ] Sub-agent writes are limited to the bounded exception — a path the orchestrator named, a new artifact under `production/`, `docs/` or `tests/`, in a step gated by `AskUserQuestion`; no per-write prompt inside those bounds, a "May I write" ask outside them; implementation files (code, shaders, audio, assets) are outside it — each agent lists the files it will create or change, and the skill asks once for the set before any is written
+- [ ] Names a destination per agent under `production/audio/[feature]/`: `direction.md` (audio-director), `sfx-spec.md` (sound-designer), `accessibility.md` (accessibility-specialist), `integration-plan.md` (technical-artist), `engine-notes.md` (engine specialist)
+- [ ] Defines a phase gate as a decision point the pipeline itself lists, whatever the `automation` mode, and claims no director spawn at phase gates
+- [ ] The compiled audio design document is written by the orchestrator only after it asks via `AskUserQuestion` "May I write the audio design to `design/audio/audio-[feature].md`?" (`design/` is outside the bounded exception)
+- [ ] Every agent prompt ends with the return contract: path written, ≤5-bullet summary, BLOCKED/CONCERNS items one line each
 - [ ] Has a next-step handoff at the end (references `/dev-story`, `/asset-audit`)
- [ ] Error Recovery Protocol section is present
- [ ] `AskUserQuestion` is used at step transitions before proceeding
- [ ] Step 2 explicitly spawns sound-designer and accessibility-specialist in parallel
+- [ ] Error Recovery Protocol section is present: verify a named artifact is on disk before treating a step as done, surface BLOCKED immediately, always produce a partial report, full procedure in `.claude/docs/error-recovery-protocol.md`
+- [ ] `AskUserQuestion` is used at step transitions before proceeding (`collaborative` mode)
+- [ ] Phase 0 resolves `review_mode`, `automation` and `team.size`, and requires a one-line active-set announcement before Step 1
+- [ ] Step 2 explicitly spawns sound-designer and accessibility-specialist in parallel, and How to Delegate lists `accessibility-specialist`
+- [ ] Step 2 labels a gameplay-critical audio event with no visual cue or subtitle BLOCKING, and Step 3 waits for the user to resolve or accept it
 - [ ] Step 3 explicitly spawns technical-artist and engine specialist in parallel (when engine is configured)
- [ ] Skill reads `design/gdd/sound-bible.md` during context gathering if it exists
- [ ] Output document is saved to `design/gdd/audio-[feature].md`
+- [ ] Skill reads the sound bible at `design/audio/sound-bible.md` during context gathering if it exists; a sound bible still at `design/gdd/sound-bible.md` (the earlier location) is read, with a recommendation to move it
+- [ ] Output document is saved to `design/audio/audio-[feature].md`

 ---

@@ -38,38 +49,42 @@ engine is configured.
 ### Case 1: Happy Path — All steps complete, audio design document saved

 **Fixture:**
+- Resolved config block: `team.size: studio`, `automation: collaborative`
+- `engine.name` in `project.yaml` is Godot
 - GDD for the target feature exists at `design/gdd/combat.md`
- Sound bible exists at `design/gdd/sound-bible.md`
+- Sound bible exists at `design/audio/sound-bible.md`
 - Existing audio assets are listed in `assets/audio/`
- Engine is configured in `.claude/docs/technical-preferences.md`
 - No accessibility gaps exist in the planned audio event list

 **Input:** `/team-audio combat`

 **Expected behavior:**
-1. Context gathering: orchestrator reads `design/gdd/combat.md`, `design/gdd/sound-bible.md`, and `assets/audio/` asset list before spawning any agent
-2. Step 1: audio-director is spawned; defines sonic identity, emotional tone, adaptive music direction, mix targets, and adaptive audio rules for combat
-3. `AskUserQuestion` presents audio direction; user approves before Step 2 begins
-4. Step 2: sound-designer and accessibility-specialist are spawned in parallel; sound-designer produces SFX specifications, audio event list with trigger conditions, and mixing groups; accessibility-specialist identifies critical gameplay audio events and specifies visual fallback and subtitle requirements
-5. `AskUserQuestion` presents SFX spec and accessibility requirements; user approves before Step 3 begins
-6. Step 3: technical-artist and primary engine specialist are spawned in parallel; technical-artist designs bus structure, middleware integration, memory budgets, and streaming strategy; engine specialist validates that the integration approach is idiomatic for the configured engine
-7. `AskUserQuestion` presents technical plan; user approves before Step 4 begins
-8. Step 4: gameplay-programmer is spawned; wires up audio events to gameplay triggers, implements adaptive music, sets up occlusion zones, writes unit tests for audio event triggers
-9. Orchestrator compiles all outputs into a single audio design document
-10. Subagent asks "May I write the audio design document to `design/gdd/audio-combat.md`?" before writing
-11. Summary output lists: audio event count, estimated asset count, implementation tasks, and any open questions
-12. Verdict: COMPLETE
+1. Before any spawn, one line announces the active set for `team.size: studio`
+2. Context gathering: orchestrator reads `design/gdd/combat.md`, `design/audio/sound-bible.md`, and `assets/audio/` asset list before spawning any agent
+3. Step 1: audio-director is spawned; defines sonic identity, emotional tone, adaptive music direction, mix targets, and adaptive audio rules for combat
+4. `AskUserQuestion` presents audio direction; user approves before Step 2 begins
+5. Step 2: sound-designer and accessibility-specialist are spawned in parallel; sound-designer produces SFX specifications, audio event list with trigger conditions, and mixing groups; accessibility-specialist identifies critical gameplay audio events and specifies visual fallback and subtitle requirements
+6. `AskUserQuestion` presents SFX spec and accessibility requirements; user approves before Step 3 begins
+7. Step 3: technical-artist and `godot-specialist` (derived from `engine.name`) are spawned in parallel; technical-artist designs bus structure, middleware integration, memory budgets, and streaming strategy; engine specialist validates that the integration approach is idiomatic for the pinned engine
+8. `AskUserQuestion` presents technical plan; user approves before Step 4 begins
+9. Step 4: gameplay-programmer is spawned; first returns the code and test files it will create or change, the orchestrator asks once for that set, and only after the yes it wires up audio events to gameplay triggers, implements adaptive music, sets up occlusion zones and writes unit tests for audio event triggers
+10. For every step, the orchestrator checks that the path named in the agent's return contract exists before treating the step as done
+11. Orchestrator compiles all outputs into a single audio design document itself (no sub-agent is re-spawned to write it)
+12. Orchestrator asks via `AskUserQuestion`: "May I write the audio design to `design/audio/audio-combat.md`?" and writes it only on approval
+13. Summary output lists: audio event count, estimated asset count, implementation tasks, and any open questions
+14. Verdict: COMPLETE

 **Assertions:**
+- [ ] Active-set line naming `team.size: studio` appears before the first agent is spawned
 - [ ] Sound bible is read during context gathering (before Step 1) when it exists
 - [ ] audio-director is spawned before sound-designer or accessibility-specialist
 - [ ] `AskUserQuestion` appears after Step 1 output and before Step 2 launch
- [ ] sound-designer and accessibility-specialist Task calls are issued simultaneously in Step 2
- [ ] technical-artist and engine specialist Task calls are issued simultaneously in Step 3
+- [ ] sound-designer and accessibility-specialist Agent calls are issued simultaneously in Step 2
+- [ ] technical-artist and `godot-specialist` Agent calls are issued simultaneously in Step 3
 - [ ] gameplay-programmer is not launched until Step 3 `AskUserQuestion` is approved
- [ ] Audio design document is written to `design/gdd/audio-combat.md` (not another path)
+- [ ] gameplay-programmer writes no code or test file before the one ask for its implementation set is answered yes
+- [ ] Audio design document is written to `design/audio/audio-combat.md` (not another path), by the orchestrator, only after its `AskUserQuestion` approval
 - [ ] Summary includes audio event count and estimated asset count
- [ ] No files are written by the orchestrator directly
 - [ ] Verdict is COMPLETE after document delivery

 ---
@@ -77,6 +92,7 @@ engine is configured.
 ### Case 2: Accessibility Gap — Critical gameplay audio event has no visual fallback

 **Fixture:**
+- Resolved config block: `team.size: studio`, `automation: collaborative`
 - GDD for the target feature exists
 - Step 1 and Step 2 are in progress
 - sound-designer's audio event list includes "EnemyNearbyAlert" — a spatial audio cue that warns the player an enemy is approaching from off-screen
@@ -86,14 +102,15 @@ engine is configured.

 **Expected behavior:**
 1. Steps 1–2 proceed; accessibility-specialist and sound-designer are spawned in parallel
-2. accessibility-specialist returns its review with a BLOCKING concern: "`EnemyNearbyAlert` is a critical gameplay audio event (warns player of off-screen threat) with no visual fallback — hearing-impaired players cannot detect this threat. This is a BLOCKING accessibility gap."
-3. Orchestrator surfaces the concern immediately in conversation before presenting `AskUserQuestion`
-4. `AskUserQuestion` presents the accessibility concern as a BLOCKING issue with options:
+2. accessibility-specialist returns its review with a BLOCKING concern: "`EnemyNearbyAlert` is a critical gameplay audio event (warns player of off-screen threat) with no visual fallback — hearing-impaired players cannot detect this threat."
+3. Orchestrator writes the concern in conversation before presenting `AskUserQuestion`
+4. `AskUserQuestion` presents the accessibility concern as a BLOCKING issue with options such as:
   - Add a visual indicator for EnemyNearbyAlert (e.g., directional arrow on HUD) and continue
   - Add controller haptic feedback as the fallback and continue
   - Stop here and resolve all accessibility gaps before proceeding to Step 3
 5. Step 3 (technical-artist + engine specialist) is not launched until the user resolves or explicitly accepts the gap
-6. The accessibility gap is included in the final audio design document under "Open Accessibility Issues" if unresolved
+6. If the user stops: a partial report of the Step 1–2 outputs is produced and the verdict is `BLOCKED — [reason]` naming the unresolved EnemyNearbyAlert gap
+7. If the user accepts the gap and continues: the gap is listed among the open questions in the final summary

 **Assertions:**
 - [ ] Accessibility gap is labeled BLOCKING (not advisory) in the report
@@ -101,7 +118,7 @@ engine is configured.
 - [ ] `AskUserQuestion` surfaces the gap before Step 3 is launched
 - [ ] At least one resolution option is offered (add visual fallback, add haptic fallback)
 - [ ] Step 3 is not launched while the gap is unresolved without explicit user authorization
- [ ] If the gap is carried forward unresolved, it is documented in the audio design doc as an open issue
+- [ ] If the user stops, the verdict is `BLOCKED — [reason]` naming the gap and the Step 1–2 outputs are kept in a partial report; if the user carries it forward, the final summary lists it as an open question

 ---

@@ -114,12 +131,12 @@ engine is configured.

 **Expected behavior:**
 1. Skill detects no argument is provided
-2. Outputs usage guidance: e.g., "Usage: `/team-audio [feature or area]` — specify the feature or area to design audio for (e.g., `combat`, `main menu`, `forest biome`, `boss encounter`)"
+2. Outputs usage guidance: e.g., "Usage: `/team-audio [feature or area to design audio for] [--review full|lean|solo]` — specify the feature or area to design audio for (e.g., `combat`, `main menu`, `forest biome`, `boss encounter`)"
 3. Skill exits without spawning any agents

 **Assertions:**
 - [ ] Skill does NOT spawn any agents when no argument is provided
- [ ] Usage message includes the correct invocation format with argument examples
+- [ ] Usage message shows the full argument-hint — `/team-audio [feature or area to design audio for] [--review full|lean|solo]` — and argument examples
 - [ ] Skill does NOT attempt to infer a feature from existing design docs without user direction
 - [ ] No `AskUserQuestion` is used — output is direct guidance

@@ -128,69 +145,72 @@ engine is configured.
 ### Case 4: Missing Sound Bible — Skill notes the gap and proceeds without it

 **Fixture:**
+- Resolved config block: `team.size: small`, `automation: collaborative`
 - GDD for the target feature exists at `design/gdd/main-menu.md`
- `design/gdd/sound-bible.md` does NOT exist
+- No sound bible exists at `design/audio/sound-bible.md` or `design/gdd/sound-bible.md`
 - Engine is configured; other context files are present

 **Input:** `/team-audio main menu`

 **Expected behavior:**
-1. Context gathering: orchestrator reads `design/gdd/main-menu.md` and checks for `design/gdd/sound-bible.md`
-2. Sound bible is not found; orchestrator notes the gap in conversation: "Note: `design/gdd/sound-bible.md` not found — audio direction will proceed without a project-wide sonic identity reference. Consider creating a sound bible if this is an ongoing project."
+1. Context gathering: orchestrator reads `design/gdd/main-menu.md` and checks for `design/audio/sound-bible.md`
+2. Sound bible is not found; orchestrator notes the gap in one line: "No sound bible at `design/audio/sound-bible.md`; audio direction starts from the GDDs alone"
 3. Pipeline proceeds normally through all four steps without the sound bible as input
 4. audio-director in Step 1 is informed that no sound bible exists and must establish sonic identity from the feature GDD alone
-5. The missing sound bible is mentioned in the final summary as a recommended next step
+5. Next Steps recommends creating the sound bible and says who writes it: the `audio-director` agent drafts `design/audio/sound-bible.md` from `.claude/docs/templates/sound-bible.md`, starting from this run's Step 1 direction, and asks before writing

 **Assertions:**
 - [ ] Orchestrator checks for the sound bible during context gathering (before Step 1)
 - [ ] Missing sound bible is noted explicitly in conversation — not silently ignored
 - [ ] Pipeline does NOT halt due to the missing sound bible
 - [ ] audio-director is notified that no sound bible exists in its prompt context
- [ ] Summary or Next Steps section recommends creating a sound bible
+- [ ] Next Steps recommends creating a sound bible and names its author — the `audio-director`, drafting from `.claude/docs/templates/sound-bible.md`
+- [ ] The skill does not write `design/audio/sound-bible.md` itself in this run
 - [ ] Verdict is still COMPLETE if all other steps succeed

 ---

-### Case 5: Engine Not Configured — Engine specialist step skipped gracefully
+### Case 5: Engine Not Configured — Engine specialist step skipped and recorded

 **Fixture:**
- Engine is NOT configured in `.claude/docs/technical-preferences.md` (shows `[TO BE CONFIGURED]`)
+- Resolved config block: `team.size: studio`, `automation: collaborative`
+- `engine.name` is unset in `project.yaml`, and `.claude/docs/technical-preferences.md` has no Primary engine specialist (shows `[TO BE CONFIGURED]`)
 - GDD for the target feature exists
 - Sound bible may or may not exist

 **Input:** `/team-audio boss encounter`

 **Expected behavior:**
-1. Context gathering: orchestrator reads `.claude/docs/technical-preferences.md` and detects no engine is configured
-2. Steps 1–2 proceed normally (audio-director, sound-designer, accessibility-specialist)
-3. Step 3: technical-artist is spawned normally; engine specialist spawn is SKIPPED
-4. Orchestrator notes in conversation: "Engine specialist not spawned — no engine configured in technical-preferences.md. Engine integration validation will be deferred until an engine is selected."
-5. Step 4: gameplay-programmer proceeds with a note that engine-specific audio integration patterns could not be validated
-6. The engine specialist gap is included in the audio design document under "Deferred Validation"
-7. Verdict: COMPLETE (skip is graceful, not a blocker)
+1. Steps 1–2 proceed normally (audio-director, sound-designer, accessibility-specialist)
+2. Step 3: technical-artist is spawned normally; engine specialist spawn is SKIPPED
+3. The run output records: `Engine validation: NOT ASSESSED — no engine configured (engine.name unset in project.yaml)`
+4. Step 4: gameplay-programmer still runs — the missing engine is not treated as a blocker
+5. Verdict: `COMPLETE — engine validation NOT ASSESSED (no engine configured)` — the skip is graceful, not a blocker, and never a plain COMPLETE

 **Assertions:**
 - [ ] Engine specialist is NOT spawned when no engine is configured
 - [ ] Skill does NOT error out due to the missing engine configuration
- [ ] The skip is explicitly noted in conversation — not silently omitted
+- [ ] The run output contains `Engine validation: NOT ASSESSED — no engine configured` with the `engine.name` reason — the skip is not silently omitted
+- [ ] Engine integration is never described as validated or passed in this run
 - [ ] technical-artist is still spawned in Step 3 (skip applies only to the engine specialist)
- [ ] gameplay-programmer proceeds in Step 4 with the deferred validation noted
- [ ] Deferred engine validation is recorded in the audio design document
- [ ] Verdict is COMPLETE (engine not configured is a known graceful case)
+- [ ] gameplay-programmer still runs in Step 4
+- [ ] Verdict is `COMPLETE — engine validation NOT ASSESSED (…)`, never a plain COMPLETE (engine not configured is a graceful case, not a blocker)

 ---

 ## Protocol Compliance

+- [ ] At the default `team.size: individual`, the run opens with `Active set (team.size: individual): sound-designer.` and a `Not spawned this run:` line naming audio-director, accessibility-specialist, technical-artist, the engine specialist and gameplay-programmer, consulted through sound-designer — before any agent is spawned
 - [ ] Context gathering (GDDs, sound bible, asset list) runs before any agent is spawned
- [ ] `AskUserQuestion` is used after every step output before the next step launches
- [ ] Parallel spawning: Step 2 (sound-designer + accessibility-specialist) and Step 3 (technical-artist + engine specialist) issue all Task calls before waiting for results
- [ ] No files are written by the orchestrator directly — all writes are delegated to sub-agents
- [ ] Each sub-agent enforces the "May I write to [path]?" protocol before any write
- [ ] BLOCKED status from any agent is surfaced immediately — not silently skipped
+- [ ] In `collaborative` mode, `AskUserQuestion` is used after every step output before the next step launches
+- [ ] Parallel spawning: Step 2 (sound-designer + accessibility-specialist) and Step 3 (technical-artist + engine specialist) issue all Agent calls before waiting for results
+- [ ] Sub-agents write only to paths the orchestrator named; they skip the per-write prompt only inside the bounded exception (`production/`, `docs/`, `tests/`)
+- [ ] The orchestrator writes the compiled audio design document only after an explicit `AskUserQuestion` approval
+- [ ] A step whose named artifact is missing on disk is treated as failed and the agent is resumed — not reported as done
+- [ ] BLOCKED status from any agent is surfaced immediately as "[AgentName]: BLOCKED — [reason]" — not silently skipped
 - [ ] A partial report is always produced when some agents complete and others block
- [ ] Audio design document path follows the pattern `design/gdd/audio-[feature].md`
- [ ] Verdict is exactly COMPLETE or BLOCKED — no other verdict values used
+- [ ] Audio design document path follows the pattern `design/audio/audio-[feature].md`
+- [ ] Verdict is exactly COMPLETE (qualified `— engine validation NOT ASSESSED ([reason])` when that step was skipped) or BLOCKED — no other verdict values used
 - [ ] Next Steps handoff references `/dev-story` and `/asset-audit`

 ---
@@ -208,3 +228,6 @@ engine is configured.
 - Engine specialist validation logic (idiomatic integration, version-specific changes) is
  tested only for the configured and unconfigured states. The specific content of the
  engine specialist's output is out of scope for this behavioral spec.
+- `guided` and `autonomous` automation modes (auto-advance, `log_decision`) are not given
+  dedicated cases; the individual-size collapse is covered by the Protocol Compliance
+  announcement check rather than a full run.
@@ -6,9 +6,15 @@ Orchestrates the full combat team pipeline end-to-end for a single combat featur
 Coordinates game-designer, gameplay-programmer, ai-programmer, technical-artist,
 sound-designer, the primary engine specialist, and qa-tester through six structured
 phases: Design → Architecture (with engine specialist validation) → Implementation
-(parallel) → Integration → Validation → Sign-off. Uses `AskUserQuestion` at each
-phase transition. Delegates all file writes to sub-agents. Produces a summary report
-with verdict COMPLETE / NEEDS WORK / BLOCKED and handoffs to `/code-review`,
+(parallel) → Integration → Validation → Sign-off. Phase 0 resolves `review_mode`,
+`automation`, `team.size` and `workflow` (which sizes the GDD); the full pipeline runs at `team.size: small` and above,
+while the default `individual` runs gameplay-programmer alone (ai-programmer only if
+AI work is flagged) and announces that collapse before Phase 1. Uses
+`AskUserQuestion` at each phase transition, with an explicit [A]/[B]/[C] architecture
+gate before implementation. Every agent writes to a destination named in the skill's
+path table; the orchestrator's only write is the GDD, `design/gdd/[feature].md`,
+from the game-designer's draft after a "May I write" approval. Produces a summary report with
+verdict COMPLETE / NEEDS WORK / BLOCKED and handoffs to `/code-review`,
 `/balance-check`, and `/team-polish`.

 ---
@@ -18,12 +24,16 @@ with verdict COMPLETE / NEEDS WORK / BLOCKED and handoffs to `/code-review`,
 - [ ] Has required frontmatter fields: `name`, `description`, `argument-hint`, `user-invocable`, `allowed-tools`
 - [ ] Has ≥2 phase headings (Phase 1 through Phase 6 are all present)
 - [ ] Contains verdict keywords: COMPLETE, NEEDS WORK, BLOCKED
- [ ] Contains "May I write" or "File Write Protocol" — writes delegated to sub-agents, orchestrator does not write files directly
+- [ ] Contains "File Write Protocol" — sub-agent drafts and QA artifacts stay inside the bounded exception, and implementation files (code root, `assets/`) are outside it, asked for once as a set; the one orchestrator write is `design/gdd/[feature].md`, after its own "May I write" ask, because `design/` is outside the exception
+- [ ] Names a concrete destination per phase: `production/combat/[feature]-gdd-draft.md` (the game-designer's draft of `design/gdd/[feature].md`), `docs/architecture/[feature]-sketch.md`, `docs/architecture/[feature]-engine-notes.md`, `production/qa/test-cases/[feature]-cases.md`, `production/qa/bugs/BUG-[NNNN].md`
+- [ ] Defines a phase gate as a decision point the pipeline itself lists, whatever the `automation` mode, and claims no director spawn at phase gates
 - [ ] Has a next-step handoff at the end (references `/code-review`, `/balance-check`, `/team-polish`)
- [ ] Error Recovery Protocol section is present with all four recovery steps
- [ ] Uses `AskUserQuestion` at phase transitions for user approval before proceeding
+- [ ] Error Recovery Protocol section is present: verify a named artifact is on disk before treating a phase as done, surface BLOCKED immediately, always produce a partial report, full procedure (surface → assess → options → partial report) in `.claude/docs/error-recovery-protocol.md`
+- [ ] Uses `AskUserQuestion` at phase transitions for user approval before proceeding (`collaborative` mode)
+- [ ] Phase 0 resolves `team.size`, and the skill requires a one-line active-set announcement before Phase 1
+- [ ] Phase 0 resolves `workflow`, and Phase 1 sizes the GDD by it: `## Summary` plus all 8 sections at `full`, the 5 standard sections plus Formulas for numeric rules at `standard`, optional at `minimal` (the game brief is the record)
 - [ ] Phase 3 is explicitly marked as parallel (gameplay-programmer, ai-programmer, technical-artist, sound-designer)
- [ ] Phase 2 includes spawning the primary engine specialist (read from `.claude/docs/technical-preferences.md`)
+- [ ] Phase 2 includes spawning the primary engine specialist, derived from `engine.name` in `project.yaml` (Godot → `godot-specialist`), falling back to the Primary line in `.claude/docs/technical-preferences.md`
 - [ ] Team Composition lists all seven roles (game-designer, gameplay-programmer, ai-programmer, technical-artist, sound-designer, engine specialist, qa-tester)

 ---
@@ -33,26 +43,34 @@ with verdict COMPLETE / NEEDS WORK / BLOCKED and handoffs to `/code-review`,
 ### Case 1: Happy Path — All agents succeed, full pipeline runs to completion

 **Fixture:**
+- Resolved config block: `team.size: small`, `automation: collaborative`, `workflow: full`
 - `design/gdd/game-concept.md` exists and is populated
- Engine is configured in `.claude/docs/technical-preferences.md` (Engine Specialists section filled)
+- `engine.name` in `project.yaml` is Godot
 - No existing GDD for the requested combat feature
+- The feature involves NPC reactions (enemies parry and riposte), so AI work is flagged

 **Input:** `/team-combat parry and riposte system`

 **Expected behavior:**
-1. Phase 1 — game-designer spawned; produces `design/gdd/parry-riposte.md` covering all 8 required sections (overview, player fantasy, rules, formulas, edge cases, dependencies, tuning knobs, acceptance criteria); asks user to approve design doc
-2. Phase 2 — gameplay-programmer + ai-programmer spawned; produce architecture sketch with class structure, interfaces, and file list; then primary engine specialist is spawned to validate idioms; engine specialist output incorporated; `AskUserQuestion` presented with architecture options before Phase 3 begins
-3. Phase 3 — gameplay-programmer, ai-programmer, technical-artist, sound-designer spawned in parallel; all four return outputs before Phase 4 begins
-4. Phase 4 — integration wires together all Phase 3 outputs; tuning knobs verified as data-driven; `AskUserQuestion` confirms integration before Phase 5
-5. Phase 5 — qa-tester spawned; writes test cases from acceptance criteria; verifies edge cases; performance impact checked against budget
-6. Phase 6 — summary report produced: design COMPLETE, all team members COMPLETE, test cases listed, verdict: COMPLETE
-7. Next steps listed: `/code-review`, `/balance-check`, `/team-polish`
+1. Before any spawn, one line announces the active set for `team.size: small` (the full Team Composition pipeline)
+2. Phase 1 — game-designer spawned; drafts the design to `production/combat/parry-riposte-gdd-draft.md` covering all 8 required sections (overview, player fantasy, rules, formulas, edge cases, dependencies, tuning knobs, acceptance criteria); `AskUserQuestion` presents the draft and asks "May I write the design document to `design/gdd/parry-riposte.md`?"; the orchestrator writes it on approval
+3. Phase 2 — gameplay-programmer + ai-programmer spawned; produce architecture sketch with class structure, interfaces, and file list (`docs/architecture/parry-riposte-sketch.md`); then `godot-specialist` is spawned to validate idioms (`docs/architecture/parry-riposte-engine-notes.md`); engine specialist output incorporated
+4. `AskUserQuestion` "Architecture sketch complete. Approve to proceed with parallel implementation." with options [A] Proceed / [B] Revise the architecture first / [C] Stop here — implementation agents spawn only on [A]
+5. Phase 3 — gameplay-programmer, ai-programmer, technical-artist, sound-designer spawned in parallel; the three implementing agents return the files they will create or change, one `AskUserQuestion` asks for the whole set, and they write only after a yes; sound-designer drafts its event list to `production/combat/parry-riposte-audio-events.md`; all four return before Phase 4 begins
+6. Phase 4 — integration wires together all Phase 3 outputs; tuning knobs verified as data-driven; `AskUserQuestion` confirms integration before Phase 5
+7. Phase 5 — qa-tester spawned; writes test cases from acceptance criteria to `production/qa/test-cases/parry-riposte-cases.md`; verifies edge cases; performance impact checked against budget
+8. Phase 6 — summary report produced: design status, implementation status per team member, test results, open issues; verdict: COMPLETE
+9. Next steps listed: `/code-review`, `/balance-check`, `/team-polish`

 **Assertions:**
- [ ] `AskUserQuestion` called at each phase gate (at minimum before Phase 3 and before Phase 5)
+- [ ] Active-set line naming `team.size: small` appears before the first agent is spawned
+- [ ] `AskUserQuestion` called at each phase transition (at minimum before Phase 3 and before Phase 5)
+- [ ] The pre-Phase 3 gate offers [A] Proceed / [B] Revise / [C] Stop, and no implementation agent is spawned unless [A] is chosen
 - [ ] Phase 3 agents launched simultaneously — no sequential dependency between gameplay-programmer, ai-programmer, technical-artist, sound-designer
 - [ ] Engine specialist runs in Phase 2 before Phase 3 begins (output incorporated into architecture)
- [ ] All file writes delegated to sub-agents (orchestrator never calls Write/Edit directly)
+- [ ] Each agent prompt names its destination from the path table; no sub-agent writes under `design/`
+- [ ] No implementation file (code root, `assets/`) is written before one ask covering the whole Phase 3 set
+- [ ] Nothing is written under `design/` before the Phase 1 "May I write" approval, and the orchestrator's only Write is `design/gdd/parry-riposte.md`
 - [ ] Verdict COMPLETE present in final report
 - [ ] Next steps include `/code-review`, `/balance-check`, `/team-polish`
 - [ ] Design doc covers all 8 required GDD sections
@@ -62,6 +80,7 @@ with verdict COMPLETE / NEEDS WORK / BLOCKED and handoffs to `/code-review`,
 ### Case 2: Blocked Agent — One subagent returns BLOCKED mid-pipeline

 **Fixture:**
+- Resolved config block: `team.size: small`, `automation: collaborative`
 - `design/gdd/parry-riposte.md` exists (Phase 1 already complete)
 - ai-programmer agent returns BLOCKED because no AI system architecture ADR exists (ADR status is Proposed)

@@ -95,12 +114,12 @@ with verdict COMPLETE / NEEDS WORK / BLOCKED and handoffs to `/code-review`,
 **Expected behavior:**
 1. Skill detects no argument provided
 2. Outputs usage message explaining the required argument (combat feature description)
-3. Provides an example invocation: `/team-combat [combat feature description]`
+3. Shows the invocation format `/team-combat [combat feature description] [--review full|lean|solo]` with examples (`melee parry system`, `ranged weapon spread`)
 4. Skill exits without spawning any subagents

 **Assertions:**
 - [ ] Skill does NOT spawn any subagents when no argument is given
- [ ] Usage message includes the argument-hint format from frontmatter
+- [ ] Usage message shows the full argument-hint: `/team-combat [combat feature description] [--review full|lean|solo]`
 - [ ] Error message includes at least one example of a valid invocation
 - [ ] No file reads beyond what is needed to detect the missing argument
 - [ ] Verdict is NOT shown (pipeline never runs)
@@ -110,61 +129,77 @@ with verdict COMPLETE / NEEDS WORK / BLOCKED and handoffs to `/code-review`,
 ### Case 4: Parallel Phase Validation — Phase 3 agents run simultaneously

 **Fixture:**
- `design/gdd/parry-riposte.md` exists and is complete
- Architecture sketch has been approved
+- Resolved config block: `team.size: small`, `automation: collaborative`
+- `design/gdd/parry-riposte.md` exists, is complete, and flags enemy AI reactions
+- Architecture sketch has been approved with option [A]
 - Engine specialist has validated architecture

 **Input:** `/team-combat parry and riposte system` (resuming from Phase 2 complete)

 **Expected behavior:**
 1. Phase 3 begins after architecture approval
-2. All four Task calls — gameplay-programmer, ai-programmer, technical-artist, sound-designer — are issued before any result is awaited
+2. All four Agent calls — gameplay-programmer, ai-programmer, technical-artist, sound-designer — are issued before any result is awaited
 3. Skill waits for all four agents to complete before proceeding to Phase 4
 4. If any single agent completes early, skill does not begin Phase 4 until all four have returned

 **Assertions:**
- [ ] Four Task calls issued in a single batch (no sequential waiting between them)
+- [ ] Four Agent calls issued in a single batch (no sequential waiting between them)
 - [ ] Phase 4 does not begin until all four Phase 3 agents have returned results
 - [ ] Skill does not pass one Phase 3 agent's output as input to another Phase 3 agent (they are independent)
 - [ ] All four Phase 3 agent results referenced in the Phase 4 integration step

 ---

-### Case 5: Architecture Phase Engine Routing — Engine specialist receives correct context
+### Case 5: Architecture Phase Engine Routing — Engine specialist resolved from config

-**Fixture:**
- `.claude/docs/technical-preferences.md` has Engine Specialists section populated (e.g., Primary: godot-specialist)
- Architecture sketch produced by gameplay-programmer is available
- Engine version pinned in `docs/engine-reference/godot/VERSION.md`
+**Fixture (variant A — engine configured):**
+- Resolved config block: `team.size: small`, `automation: collaborative`
+- `engine.name` in `project.yaml` is Godot; engine version pinned in `docs/engine-reference/godot/VERSION.md`
+- Architecture sketch produced by gameplay-programmer is available, and the orchestrator has read it
+
+**Fixture (variant B — no engine configured):**
+- As variant A, except `engine.name` is unset in `project.yaml` and `.claude/docs/technical-preferences.md` has no Primary engine specialist (shows `[TO BE CONFIGURED]`)

 **Input:** `/team-combat parry and riposte system`

-**Expected behavior:**
+**Expected behavior (variant A):**
 1. Phase 2 — gameplay-programmer produces architecture sketch
-2. Skill reads `.claude/docs/technical-preferences.md` Engine Specialists section to identify the primary engine specialist agent type
-3. Engine specialist is spawned with: the architecture sketch, the GDD path, the engine version from `VERSION.md`, and explicit instructions to check for deprecated APIs
-4. Engine specialist output (idiom notes, deprecated API warnings, native system recommendations) is returned to orchestrator
+2. Skill derives the primary engine specialist from `engine.name` (Godot → `godot-specialist`); `technical-preferences.md` is consulted only if `engine.name` is absent
+3. Engine specialist is spawned with a distilled brief of the architecture sketch (not a path to a document the orchestrator has already read) and asked the three Phase 2 questions: idiomatic class/node structure, engine-native systems to prefer, APIs deprecated or changed in the pinned engine version
+4. Engine specialist writes its notes to `docs/architecture/parry-riposte-engine-notes.md`; the orchestrator checks the file exists before treating the step as done
 5. Orchestrator incorporates engine notes into the architecture before presenting Phase 2 results to user
-6. `AskUserQuestion` includes engine specialist's notes alongside the architecture sketch
+6. `AskUserQuestion` architecture gate includes engine specialist's notes alongside the architecture sketch
+
+**Expected behavior (variant B):**
+1. Phase 2 — gameplay-programmer produces architecture sketch
+2. No engine specialist is spawned and no engine-notes file is expected
+3. The run output records `Engine validation: NOT ASSESSED — no engine configured (engine.name unset in project.yaml)`
+4. The architecture gate still runs; it presents the sketch without describing it as engine-validated
+5. When the run completes, the verdict is `COMPLETE — engine validation NOT ASSESSED (no engine configured)`

 **Assertions:**
- [ ] Engine specialist agent type is read from `.claude/docs/technical-preferences.md` — not hardcoded
- [ ] Engine specialist prompt includes the architecture sketch and GDD path
- [ ] Engine specialist checks for deprecated APIs against the pinned engine version
- [ ] Engine specialist output is incorporated before Phase 3 begins (not skipped or appended separately)
- [ ] If no engine is configured, engine specialist step is skipped and a note is added to the report
+- [ ] Engine specialist agent type is derived from `engine.name` (falling back to `technical-preferences.md`) — not hardcoded (variant A)
+- [ ] Because the orchestrator has already read the sketch, the engine specialist's brief carries the relevant sketch content inline rather than the sketch's path (variant A)
+- [ ] Engine specialist checks for deprecated or changed APIs against the pinned engine version (variant A)
+- [ ] Engine specialist output is incorporated before Phase 3 begins (not skipped or appended separately) (variant A)
+- [ ] The engine specialist is not spawned and the run output records `Engine validation: NOT ASSESSED — no engine configured` — the skip is never silent (variant B)
+- [ ] The architecture is never described as engine-validated when no specialist ran (variant B)
+- [ ] When the run completes, its verdict reads `COMPLETE — engine validation NOT ASSESSED ([reason])` — never a plain COMPLETE (variant B)

 ---

 ## Protocol Compliance

- [ ] `AskUserQuestion` used at each phase transition — user approves before pipeline advances
- [ ] All file writes delegated to sub-agents via Task — orchestrator does not call Write or Edit directly
+- [ ] At the default `team.size: individual`, the run opens with an `Active set (team.size: individual): gameplay-programmer` line and a `Not spawned this run:` line naming game-designer, technical-artist, sound-designer, the engine specialist and qa-tester (ai-programmer too unless AI work is flagged) — before any agent is spawned
+- [ ] In `collaborative` mode, `AskUserQuestion` used at each phase transition — user approves before pipeline advances
+- [ ] Sub-agent writes are delegated via Agent — drafts and QA artifacts inside the bounded exception, implementation files only after one ask for the whole set; the orchestrator writes only `design/gdd/[feature].md`, after a "May I write" approval
 - [ ] Error Recovery Protocol followed: surface → assess → offer options → partial report
+- [ ] A phase whose named artifact is missing on disk is treated as failed, not done
 - [ ] Phase 3 agents launched in parallel per skill spec
 - [ ] Partial report always produced even when agents are BLOCKED
 - [ ] Verdict is one of COMPLETE / NEEDS WORK / BLOCKED
 - [ ] Next steps present at end of output: `/code-review`, `/balance-check`, `/team-polish`
+- [ ] At `team.size: studio`, the primary engine specialist's prompt allows its sub-specialists, Phase 5's qa-tester is told to find how the feature breaks rather than confirm it works, and the report says the adversarial pass ran; below `studio` neither addition appears

 ---

@@ -176,5 +211,6 @@ with verdict COMPLETE / NEEDS WORK / BLOCKED and handoffs to `/code-review`,
  recursive behavior (splitting via `/create-stories`) is covered by the `/create-stories` spec.
 - Phase 4 integration logic (wiring gameplay, AI, VFX, audio) is validated implicitly by
  the Happy Path case; a dedicated integration test would require fixture code files.
- Engine specialist unavailable (no engine configured) is partially covered in Case 5
-  assertions — a dedicated fixture for unconfigured engine state would strengthen coverage.
+- Engine specialist unavailable (no engine configured) is covered by Case 5 variant B.
+- The `studio` additions (engine sub-specialists, adversarial review pass) are asserted in
+  Protocol Compliance but not given their own case.
@@ -4,12 +4,18 @@

 Orchestrates the full level design team for a single level or area. Coordinates
 narrative-director, world-builder, level-designer, systems-designer, art-director,
-accessibility-specialist, and qa-tester through five sequential steps with one
-parallel phase (Step 4). Compiles all team outputs into a single level design
-document saved to `design/levels/[level-name].md`. Uses `AskUserQuestion` at each
-step transition. Delegates all file writes to sub-agents. Produces a summary report
-with verdict COMPLETE / BLOCKED and handoffs to `/design-review`, `/dev-story`,
-`/qa-plan`.
+accessibility-specialist, and qa-tester through five steps: narrative + visual
+direction in parallel (Step 1), layout (Step 2), systems (Step 3), production
+concepts + accessibility in parallel (Step 4), and QA planning (Step 5). Phase 0
+resolves `review_mode`, `automation` and `team.size` and the skill announces the
+active set before Step 1 — `individual` spawns level-designer alone, `small` adds
+systems-designer + art-director + qa-tester, `studio` adds narrative-director,
+world-builder and accessibility-specialist. The orchestrator compiles all team
+outputs itself and writes `design/levels/[level-name].md` only after asking "May I
+write…?" via `AskUserQuestion`; per-agent artifacts are written by sub-agents under
+the bounded write exception. Uses `AskUserQuestion` at each step gate. Produces a
+summary report with verdict COMPLETE / BLOCKED and handoffs to `/design-review`,
+`/dev-story`, `/qa-plan`.

 ---

@@ -18,15 +24,19 @@ with verdict COMPLETE / BLOCKED and handoffs to `/design-review`, `/dev-story`,
 - [ ] Has required frontmatter fields: `name`, `description`, `argument-hint`, `user-invocable`, `allowed-tools`
 - [ ] Has ≥2 phase/step headings (Step 1 through Step 5 are all present)
 - [ ] Contains verdict keywords: COMPLETE, BLOCKED
- [ ] Contains "May I write" or "File Write Protocol" — writes delegated to sub-agents, orchestrator does not write files directly
+- [ ] File Write Protocol: per-agent artifacts are written by sub-agents under the bounded exception (named path, new artifact under `production/`, `docs/` or `tests/`, gated step); the one exception is the compiled level doc, which the orchestrator writes itself after its own "May I write …?" prompt
+- [ ] Names a destination per agent under `production/levels/[level-name]/` — `narrative.md`, `lore.md`, `visual-direction.md`, `layout.md`, `systems.md`, `production-concepts.md`, `accessibility.md` — and qa-tester's at `production/qa/test-cases/[level-name]-cases.md`
+- [ ] Defines a phase gate as a decision point the pipeline itself lists, whatever the `automation` mode, and claims no director spawn at phase gates
 - [ ] Has a next-step handoff at the end (references `/design-review`, `/dev-story`, `/qa-plan`)
- [ ] Error Recovery Protocol section is present with all four recovery steps
- [ ] Uses `AskUserQuestion` at step transitions for user approval before proceeding
- [ ] Step 4 is explicitly marked as parallel (art-director and accessibility-specialist run simultaneously)
- [ ] Context gathering reads: `design/gdd/game-concept.md`, `design/gdd/game-pillars.md`, `design/levels/`, `design/narrative/`, and relevant world-building docs
- [ ] Team Composition lists all seven roles (narrative-director, world-builder, level-designer, systems-designer, art-director, accessibility-specialist, qa-tester)
+- [ ] Error Recovery Protocol section is present: verify a named artifact is on disk before treating a step as done, surface BLOCKED immediately, always produce a partial report, full procedure (surface → assess → options → partial report) in `.claude/docs/error-recovery-protocol.md`
+- [ ] Uses `AskUserQuestion` at step transitions for user approval before proceeding (`collaborative` mode)
+- [ ] Phase 0 resolves `team.size`, and the skill requires a one-line active-set announcement before Step 1
+- [ ] Step 1 explicitly spawns narrative-director, world-builder and art-director in parallel
+- [ ] Step 4 is explicitly marked as parallel (art-director and accessibility-specialist run simultaneously) and waits for both
+- [ ] Context gathering reads: `design/gdd/game-concept.md` (or `design/game-brief.md`), `design/gdd/game-pillars.md`, `design/levels/`, `design/narrative/`, and relevant world-building docs
+- [ ] `## How to Delegate` lists all seven roles (narrative-director, world-builder, level-designer, systems-designer, art-director, accessibility-specialist, qa-tester)
 - [ ] accessibility-specialist output includes severity ratings (BLOCKING / RECOMMENDED / NICE TO HAVE)
- [ ] Final level design document saved to `design/levels/[level-name].md`
+- [ ] Final level design document saved to `design/levels/[level-name].md`, where `[level-name]` is the argument slugged — lowercase, spaces → hyphens — and adjacent-area paths use the same rule

 ---

@@ -35,30 +45,35 @@ with verdict COMPLETE / BLOCKED and handoffs to `/design-review`, `/dev-story`,
 ### Case 1: Happy Path — All team members produce outputs, document compiled and saved

 **Fixture:**
+- Resolved config block: `team.size: studio`, `automation: collaborative`
 - `design/gdd/game-concept.md` exists and is populated
 - `design/gdd/game-pillars.md` exists
 - `design/levels/` directory exists (may contain other level docs)
 - `design/narrative/` directory exists with relevant narrative docs
+- World-building docs for the forest region exist

 **Input:** `/team-level forest dungeon`

 **Expected behavior:**
-1. Context gathering — orchestrator reads game-concept.md, game-pillars.md, existing level docs in `design/levels/`, narrative docs in `design/narrative/`, and world-building docs for the forest region
-2. Step 1 — narrative-director spawned: defines narrative purpose, key characters, dialogue triggers, emotional arc; world-builder spawned: provides lore context, environmental storytelling opportunities, world rules; `AskUserQuestion` confirms Step 1 outputs before Step 2
-3. Step 2 — level-designer spawned: designs spatial layout (critical path, optional paths, secrets), pacing curve, encounters, puzzles, entry/exit points and connections to adjacent areas; `AskUserQuestion` confirms layout before Step 3
-4. Step 3 — systems-designer spawned: specifies enemy compositions, loot tables, difficulty balance, area-specific mechanics, resource distribution; `AskUserQuestion` confirms systems before Step 4
-5. Step 4 — art-director and accessibility-specialist spawned in parallel; art-director: visual theme, color palette, lighting, asset list, VFX needs; accessibility-specialist: navigation clarity, colorblind safety, cognitive load check — each concern rated BLOCKING / RECOMMENDED / NICE TO HAVE; `AskUserQuestion` presents both outputs before Step 5
-6. Step 5 — qa-tester spawned: test cases for critical path, boundary/edge cases (sequence breaks, softlocks), playtest checklist, acceptance criteria
-7. Orchestrator compiles all team outputs into level design document format; sub-agent asked "May I write to `design/levels/forest-dungeon.md`?"; file saved
-8. Summary report: area overview, encounter count, estimated asset list, narrative beats, cross-team dependencies, verdict: COMPLETE
-9. Next steps listed: `/design-review design/levels/forest-dungeon.md`, `/dev-story`, `/qa-plan`
+1. Before any spawn, one line announces the active set for `team.size: studio`
+2. Context gathering — orchestrator reads game-concept.md, game-pillars.md, existing level docs in `design/levels/`, narrative docs in `design/narrative/`, and world-building docs for the forest region
+3. Step 1 — narrative-director, world-builder and art-director are spawned together (all three Agent calls issued before any result is awaited): narrative purpose and emotional arc; lore context and world rules; visual theme targets, lighting mood, shape language and landmarks; `AskUserQuestion` presents all three outputs before Step 2
+4. Step 2 — level-designer spawned with the Step 1 outputs, including the art-director's visual targets as explicit constraints; designs spatial layout, pacing curve, encounters, puzzles, entry/exit points; orchestrator checks `design/levels/` for every adjacent area referenced; `AskUserQuestion` confirms layout before Step 3
+5. Step 3 — systems-designer spawned: enemy compositions, loot tables, difficulty balance, area-specific mechanics, resource distribution; `AskUserQuestion` confirms systems before Step 4
+6. Step 4 — art-director (location-specific production concepts) and accessibility-specialist spawned in parallel; each accessibility concern rated BLOCKING / RECOMMENDED / NICE TO HAVE; orchestrator waits for both; `AskUserQuestion` presents both outputs before Step 5
+7. Step 5 — qa-tester spawned: test cases for critical path, boundary/edge cases (sequence breaks, softlocks), playtest checklist, acceptance criteria
+8. Orchestrator compiles all team outputs into the level design template itself — it does not re-spawn level-designer to do it — then asks via `AskUserQuestion`: "May I write the compiled level design to `design/levels/forest-dungeon.md`?" and writes on approval
+9. Summary report: area overview, encounter count, estimated asset list, narrative beats, cross-team dependencies, open cross-level dependencies, accessibility concerns with resolution status; verdict: COMPLETE
+10. Next steps listed: `/design-review design/levels/forest-dungeon.md`, `/dev-story`, `/qa-plan`

 **Assertions:**
+- [ ] Active-set line naming `team.size: studio` appears before the first agent is spawned
 - [ ] All five sources read during context gathering before any agent is spawned
- [ ] narrative-director and world-builder both spawned in Step 1 (may be sequential or parallel — both must complete before Step 2)
+- [ ] narrative-director, world-builder and art-director Agent calls are issued in parallel in Step 1, and all three complete before Step 2
+- [ ] The level-designer brief carries the art-director's Step 1 visual targets as constraints
 - [ ] `AskUserQuestion` called at each step gate (minimum: after Step 1, Step 2, Step 3, Step 4)
 - [ ] Step 4 agents (art-director, accessibility-specialist) launched simultaneously
- [ ] All file writes delegated to sub-agents — orchestrator does not write directly
+- [ ] The compiled level doc is written by the orchestrator, not a re-spawned agent, and only after its own "May I write" approval
 - [ ] Level doc saved to `design/levels/forest-dungeon.md` (slugified from argument)
 - [ ] Verdict COMPLETE in final summary report
 - [ ] Next steps include `/design-review`, `/dev-story`, `/qa-plan`
@@ -69,6 +84,7 @@ with verdict COMPLETE / BLOCKED and handoffs to `/design-review`, `/dev-story`,
 ### Case 2: Blocked Agent (world-builder) — Partial report produced with gap noted

 **Fixture:**
+- Resolved config block: `team.size: studio`, `automation: collaborative`
 - `design/gdd/game-concept.md` exists
 - World-building docs for the forest region do NOT exist
 - world-builder agent returns BLOCKED: "No world-building docs found for the forest region — cannot provide lore context"
@@ -76,23 +92,23 @@ with verdict COMPLETE / BLOCKED and handoffs to `/design-review`, `/dev-story`,
 **Input:** `/team-level forest dungeon`

 **Expected behavior:**
-1. Context gathering completes; missing world-building docs noted
-2. Step 1 — narrative-director completes successfully; world-builder spawned and returns BLOCKED
+1. Context gathering completes
+2. Step 1 — narrative-director and art-director complete successfully; world-builder returns BLOCKED
 3. Error Recovery Protocol triggered: "world-builder: BLOCKED — no world-building docs for forest region"
 4. `AskUserQuestion` presented with options:
-   - (a) Skip world-builder and note the lore gap in the level doc
+   - (a) Skip world-builder and note the gap in the final report
   - (b) Retry with narrower scope (world-builder focuses only on what can be inferred from game-concept.md)
   - (c) Stop here and create world-building docs first
-5. If user chooses (a): pipeline continues with Steps 2–5 using narrative-director context only; level doc compiled with a clearly marked gap section: "World-building context: NOT PROVIDED — see open dependency"
-6. Final report produced: partial outputs documented, world-builder section marked BLOCKED, overall verdict: BLOCKED
+5. If user chooses (a): pipeline continues with Steps 2–5 without a lore foundation; the missing world-building context is listed as a gap in the final report
+6. If the world-builder remains unresolved, the final report marks the world-builder section BLOCKED and the overall verdict is BLOCKED

 **Assertions:**
 - [ ] BLOCKED surface message appears immediately when world-builder fails — before Step 2 begins without user input
 - [ ] `AskUserQuestion` offers at minimum three options (skip / retry / stop)
- [ ] Partial report produced — narrative-director's completed work is not discarded
- [ ] Level doc (if compiled) contains an explicit gap notation for the missing world-building context
+- [ ] Partial report produced — narrative-director's and art-director's completed work is not discarded
+- [ ] The missing world-building context is named as a gap in the final report
 - [ ] Overall verdict is BLOCKED (not COMPLETE) when world-builder remains unresolved
- [ ] Skill does NOT silently fabricate lore content to fill the gap
+- [ ] Nothing is written in world-builder's place — the protocol's option is "skip this agent and note the gap" (`.claude/docs/error-recovery-protocol.md`), not substitute lore

 ---

@@ -106,12 +122,12 @@ with verdict COMPLETE / BLOCKED and handoffs to `/design-review`, `/dev-story`,
 **Expected behavior:**
 1. Skill detects no argument provided
 2. Outputs usage message explaining the required argument (level name or area to design)
-3. Provides example invocations: `/team-level tutorial`, `/team-level forest dungeon`, `/team-level final boss arena`
+3. Shows the invocation format `/team-level [level name or area to design] [--review full|lean|solo]` with examples (`forest temple`, `tutorial village`, `final boss arena`)
 4. Skill exits without reading any project files or spawning any subagents

 **Assertions:**
 - [ ] Skill does NOT spawn any subagents when no argument is given
- [ ] Usage message includes the argument-hint format from frontmatter
+- [ ] Usage message shows the full argument-hint: `/team-level [level name or area to design] [--review full|lean|solo]`
 - [ ] At least one example of a valid invocation is shown
 - [ ] No GDD or level files read before failing
 - [ ] Verdict is NOT shown (pipeline never starts)
@@ -121,23 +137,23 @@ with verdict COMPLETE / BLOCKED and handoffs to `/design-review`, `/dev-story`,
 ### Case 4: Accessibility Review Gate — Blocking concern surfaces before sign-off

 **Fixture:**
+- Resolved config block: `team.size: studio`, `automation: collaborative`
 - Steps 1–3 complete successfully
- `design/accessibility-requirements.md` committed tier: Enhanced
+- `design/accessibility-requirements.md` committed tier: Standard
 - accessibility-specialist (Step 4, parallel) flags a BLOCKING concern: the critical path through the forest dungeon requires players to distinguish between two environmental hazards (toxic pools vs. shallow water) using color alone — no shape, icon, or audio cue differentiates them

 **Input:** `/team-level forest dungeon`

 **Expected behavior:**
 1. Steps 1–3 complete; Step 4 parallel phase begins
-2. accessibility-specialist returns: BLOCKING concern — "Critical path hazard distinction relies on color only (toxic pools vs. shallow water). Shape, icon, or audio cue required per Enhanced accessibility tier."
+2. accessibility-specialist returns: BLOCKING concern — "Critical path hazard distinction relies on color only (toxic pools vs. shallow water). Shape, icon, or audio cue required per Standard accessibility tier."
 3. art-director returns Step 4 output (complete)
 4. Skill presents both Step 4 results via `AskUserQuestion` — BLOCKING concern highlighted prominently
 5. `AskUserQuestion` offers:
-   - (a) Return to level-designer + art-director to redesign hazard visual/audio language before Step 5
-   - (b) Document as a known accessibility gap and proceed to Step 5 with the concern logged
-6. Skill does NOT silently proceed past the BLOCKING concern
-7. If user chooses (a): level-designer and art-director revision spawned; re-run Step 4 accessibility check
-8. Final report includes BLOCKING concern and its resolution status regardless of user choice
+   - (a) Return to level-designer + 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
+6. Skill does NOT proceed to Step 5 until the user acknowledges the BLOCKING concern
+7. Final summary lists the accessibility concern and its resolution status regardless of user choice

 **Assertions:**
 - [ ] BLOCKING accessibility concern is not treated as advisory — it is surfaced as a blocker
@@ -152,6 +168,7 @@ with verdict COMPLETE / BLOCKED and handoffs to `/design-review`, `/dev-story`,
 ### Case 5: Circular Level Reference — Adjacent area dependency flagged

 **Fixture:**
+- Resolved config block: `automation: collaborative` (any `team.size` — level-designer is active at every size)
 - Steps 1–3 in progress
 - level-designer (Step 2) produces a layout that specifies entry/exit points connecting to "the crystal caves" (an adjacent area)
 - `design/levels/crystal-caves.md` does NOT exist — the crystal caves area has not been designed yet
@@ -160,13 +177,13 @@ with verdict COMPLETE / BLOCKED and handoffs to `/design-review`, `/dev-story`,

 **Expected behavior:**
 1. Step 2 — level-designer produces layout including: "West exit connects to crystal-caves entry point A"
-2. Orchestrator (or level-designer subagent) checks `design/levels/` for `crystal-caves.md`; file not found
+2. Orchestrator checks `design/levels/` for `crystal-caves.md`; file not found
 3. Dependency gap surfaced: "Level references crystal-caves as an adjacent area but `design/levels/crystal-caves.md` does not exist"
 4. `AskUserQuestion` presented with options:
   - (a) Proceed with a placeholder reference — note the dependency in the level doc as UNRESOLVED
   - (b) Pause and run `/team-level crystal caves` first to establish that area
 5. Skill does NOT invent crystal caves content to satisfy the reference
-6. If user chooses (a): level doc compiled with the west exit marked "→ crystal-caves (UNRESOLVED — area not yet designed)"; flagged in the open dependencies section of the summary report
+6. If user chooses (a): level doc compiled with the west exit marked UNRESOLVED; flagged in the open cross-level dependencies section of the summary report
 7. Final report includes open cross-level dependencies section

 **Assertions:**
@@ -181,12 +198,14 @@ with verdict COMPLETE / BLOCKED and handoffs to `/design-review`, `/dev-story`,

 ## Protocol Compliance

- [ ] `AskUserQuestion` used at each step transition — user approves before pipeline advances
- [ ] All file writes delegated to sub-agents via Task — orchestrator does not call Write or Edit directly
+- [ ] At the default `team.size: individual`, the run opens with an `Active set (team.size: individual): level-designer` line and a `Not spawned this run:` line naming every other agent the pipeline names — before any agent is spawned
+- [ ] In `collaborative` mode, `AskUserQuestion` used at each step transition — user approves before pipeline advances
+- [ ] Per-agent artifacts are written by sub-agents to paths the orchestrator named; only the compiled level doc is written by the orchestrator, after its own `AskUserQuestion` approval
+- [ ] A step whose named artifact is missing on disk is treated as failed, not done
 - [ ] Error Recovery Protocol followed: surface → assess → offer options → partial report
- [ ] Step 4 agents (art-director, accessibility-specialist) launched in parallel per skill spec
+- [ ] Step 1 (narrative-director, world-builder, art-director) and Step 4 (art-director, accessibility-specialist) launched in parallel per skill spec
 - [ ] Partial report always produced even when agents are BLOCKED
- [ ] Accessibility BLOCKING concerns surface before sign-off and require explicit user acknowledgment
+- [ ] Accessibility BLOCKING concerns surface before Step 5 and require explicit user acknowledgment
 - [ ] Verdict is one of COMPLETE / BLOCKED
 - [ ] Next steps present at end: `/design-review`, `/dev-story`, `/qa-plan`

@@ -194,9 +213,6 @@ with verdict COMPLETE / BLOCKED and handoffs to `/design-review`, `/dev-story`,

 ## Coverage Notes

- narrative-director and world-builder in Step 1 may be sequential or parallel — the skill spec
-  spawns both but does not mandate simultaneous launch; coverage of parallel Step 1 would require
-  an explicit timing assertion fixture.
 - The "Retry with narrower scope" option in the blocked world-builder case (Case 2) — the
  retry behavior itself is not tested in depth; its full path is analogous to the blocked agent
  pattern covered in Case 2 and in other team-* specs.
@@ -204,6 +220,7 @@ with verdict COMPLETE / BLOCKED and handoffs to `/design-review`, `/dev-story`,
  Protocol applies and the pattern is validated by Case 2.
 - Step 4 parallel ordering (art-director completing before or after accessibility-specialist)
  does not affect outcomes — both must return before Step 5 regardless of order.
- The level doc slug convention (argument → filename) is implicitly tested by Case 1
-  (`forest dungeon` → `forest-dungeon.md`); multi-word slugification edge cases (special
-  characters, very long names) are not covered.
+- The level doc slug rule (lowercase, spaces → hyphens) is exercised by Case 1
+  (`forest dungeon` → `forest-dungeon.md`) and Case 5 (`crystal caves` →
+  `crystal-caves.md`); special characters and very long names are not covered.
+- The `small` active set (systems-designer + art-director added) is not given its own case.
@@ -4,9 +4,17 @@

 Orchestrates the live-ops team through a 7-phase planning pipeline to produce a
 season or event plan. Coordinates live-ops-designer, economy-designer,
-analytics-engineer, community-manager, narrative-director, and writer. Phases 3
-and 4 (economy design and analytics) run simultaneously. Ends with a consolidated
-season plan requiring user approval before handoff to production.
+analytics-engineer, community-manager, narrative-director, and writer. Phase 0
+resolves `review_mode`, `automation` and `team.size` and the skill announces the
+active set before Phase 1 — `individual` spawns live-ops-designer + economy-designer,
+`small` adds analytics-engineer + community-manager, `studio` adds writer +
+narrative-director. Phases 3 and 4 (economy design and analytics) run
+simultaneously. Phase 7 checks the economy design against
+`design/live-ops/ethics-policy.md`. Sub-agents write working artifacts under
+`production/`; the orchestrator compiles the final documents and writes them to
+`design/live-ops/seasons/` only after asking "May I write the season plan to
+`design/live-ops/…`?" via `AskUserQuestion`. Ends with a consolidated season plan
+requiring user approval before handoff to production.

 ---

@@ -15,12 +23,15 @@ season plan requiring user approval before handoff to production.
 - [ ] Has required frontmatter fields: `name`, `description`, `argument-hint`, `user-invocable`, `allowed-tools`
 - [ ] Has ≥2 phase headings
 - [ ] Contains verdict keywords: COMPLETE, BLOCKED
- [ ] Contains "May I write" language in the File Write Protocol section (delegated to sub-agents)
- [ ] Has a File Write Protocol section stating that the orchestrator does not write files directly
+- [ ] Output Documents section: the orchestrator asks via `AskUserQuestion` "May I write the season plan to `design/live-ops/…`?" before writing, because `design/` is outside the bounded write exception
+- [ ] Has a File Write Protocol section limiting sub-agent writes to the bounded exception (named path, new artifact under `production/`, `docs/` or `tests/`, gated phase) — a sub-agent asks outside those bounds
+- [ ] Names a destination per agent under `production/live-ops/[season-slug]/` — `brief.md`, `narrative.md`, `economy.md`, `analytics.md`, `narrative-text.md`, `copy.md`, `comms.md` — one file per agent
+- [ ] Defines a phase gate as a decision point the pipeline itself lists, whatever the `automation` mode, and claims no director spawn at phase gates
 - [ ] Has a next-step handoff at the end referencing `/design-review`, `/sprint-plan`, and `/team-release`
- [ ] Uses `AskUserQuestion` at phase transitions to capture user approval before proceeding
+- [ ] Uses `AskUserQuestion` at phase transitions to capture user approval before proceeding (`collaborative` mode)
+- [ ] Phase 0 resolves `team.size`, and the skill requires a one-line active-set announcement before Phase 1
 - [ ] States explicitly that Phases 3 and 4 can run simultaneously (parallel spawning)
- [ ] Error recovery section present (or implied through BLOCKED handling)
+- [ ] Error recovery section present: verify a named artifact is on disk, surface BLOCKED immediately, always produce a partial report, end with BLOCKED if unresolvable
 - [ ] Output documents section specifies paths under `design/live-ops/seasons/`

 ---
@@ -30,6 +41,7 @@ season plan requiring user approval before handoff to production.
 ### Case 1: Happy Path — All 7 phases complete, season plan produced

 **Fixture:**
+- Resolved config block: `team.size: studio`, `automation: collaborative`
 - `design/live-ops/economy-rules.md` exists with current economy configuration
 - `design/live-ops/ethics-policy.md` exists with the project ethics policy
 - Game concept document exists at its standard path
@@ -38,24 +50,26 @@ season plan requiring user approval before handoff to production.
 **Input:** `/team-live-ops "Season 2: The Frozen Wastes"`

 **Expected behavior:**
-1. Phase 1: Spawns `live-ops-designer` via Task; receives season brief with scope, content list, and retention mechanic; presents to user
-2. AskUserQuestion: user approves Phase 1 output before Phase 2 begins
-3. Phase 2: Spawns `narrative-director` via Task; reads the Phase 1 season brief; produces narrative framing document (theme, story hook, lore connections); presents to user
-4. Phase 3 and 4 (parallel): Spawns `economy-designer` and `analytics-engineer` simultaneously via two Task calls before waiting for either result; economy-designer reads `design/live-ops/economy-rules.md`
-5. Phase 5: Spawns `narrative-director` and `writer` in parallel to produce in-game narrative text and player-facing copy; both read Phase 2 narrative framing doc
-6. Phase 6: Spawns `community-manager` via Task; reads season brief, economy design, and narrative framing; produces communication calendar with draft copy
-7. Phase 7: Collects all phase outputs; presents consolidated season plan summary including economy health check, analytics readiness, ethics review, and open questions
-8. AskUserQuestion: user approves the full season plan
-9. Sub-agents ask "May I write to `design/live-ops/seasons/S2_The_Frozen_Wastes.md`?", `...analytics.md`, and `...comms.md` before writing
-10. Verdict: COMPLETE — season plan produced and handed off for production
+1. Before any spawn, one line announces the active set for `team.size: studio`
+2. Phase 1: Spawns `live-ops-designer` via Agent; receives season brief with scope, content list, and retention mechanic; presents to user
+3. AskUserQuestion: user approves Phase 1 output before Phase 2 begins
+4. Phase 2: Spawns `narrative-director` via Agent; reads the Phase 1 season brief; produces narrative framing document (theme, story hook, lore connections); presents to user
+5. Phase 3 and 4 (parallel): Spawns `economy-designer` and `analytics-engineer` simultaneously via two Agent calls before waiting for either result; economy-designer reads `design/live-ops/economy-rules.md`
+6. Phase 5: Spawns `narrative-director` and `writer` in parallel to produce in-game narrative text and player-facing copy; both read Phase 2 narrative framing doc
+7. Phase 6: Spawns `community-manager` via Agent; reads season brief, economy design, and narrative framing; produces communication calendar with draft copy
+8. Phase 7: Collects all phase outputs; presents consolidated season plan summary including economy health check, analytics readiness, ethics review against `design/live-ops/ethics-policy.md`, and open questions
+9. AskUserQuestion: user approves the full season plan
+10. Orchestrator compiles the three documents and asks via AskUserQuestion "May I write the season plan to `design/live-ops/seasons/…`?" covering `S2_[name].md`, `S2_[name]_analytics.md` and `S2_[name]_comms.md`; writes only on approval
+11. Verdict: COMPLETE — season plan produced and handed off for production

 **Assertions:**
- [ ] All 7 phases execute in order; Phase 3 and 4 are issued as parallel Task calls
+- [ ] Active-set line naming `team.size: studio` appears before the first agent is spawned
+- [ ] All 7 phases execute in order; Phase 3 and 4 are issued as parallel Agent calls
 - [ ] Phase 7 consolidated summary includes all six sections (season brief, narrative framing, economy design, analytics plan, content inventory, communication calendar)
 - [ ] Ethics review section in Phase 7 explicitly references `design/live-ops/ethics-policy.md`
- [ ] Three output documents written to `design/live-ops/seasons/` with correct naming convention
- [ ] File writes are delegated to sub-agents — orchestrator does not write directly
- [ ] Verdict: COMPLETE appears in final output
+- [ ] Three output documents written to `design/live-ops/seasons/` with the `S[N]_[name].md`, `S[N]_[name]_analytics.md`, `S[N]_[name]_comms.md` naming convention
+- [ ] The `design/live-ops/` documents are written by the orchestrator only after its `AskUserQuestion` approval — no sub-agent writes under `design/`
+- [ ] Verdict: COMPLETE appears in final output, only after the user approves the season plan
 - [ ] Next steps reference `/design-review`, `/sprint-plan`, and `/team-release`

 ---
@@ -64,15 +78,15 @@ season plan requiring user approval before handoff to production.

 **Fixture:**
 - All standard live-ops fixtures present (economy-rules.md, ethics-policy.md)
- `design/live-ops/ethics-policy.md` explicitly prohibits loot boxes targeting players under 18
- economy-designer (Phase 3) proposes a "Mystery Chest" mechanic with randomized premium rewards and no pity timer
+- `design/live-ops/ethics-policy.md` contains the rule "No randomized premium rewards without published drop rates and a pity timer"
+- economy-designer (Phase 3) proposes a "Mystery Chest" mechanic with randomized premium rewards, unpublished drop rates and no pity timer

 **Input:** `/team-live-ops "Season 3: Shadow Tournament"`

 **Expected behavior:**
 1. Phases 1–4 proceed normally; economy-designer proposes Mystery Chest mechanic
-2. Phase 7: Orchestrator reviews Phase 3 output against ethics policy; identifies Mystery Chest as a violation of the "no untransparent random premium rewards" rule in the ethics policy
-3. Ethics review section of the Phase 7 summary flags the violation explicitly: "ETHICS FLAG: Mystery Chest mechanic in Phase 3 economy design violates [policy rule]. Approval is blocked until this is resolved."
+2. Phase 7: Orchestrator reviews Phase 3 output against ethics policy; identifies Mystery Chest as a violation of the policy's "No randomized premium rewards without published drop rates and a pity timer" rule
+3. Ethics review section of the Phase 7 summary flags the violation explicitly: "ETHICS FLAG: Mystery Chest mechanic in Phase 3 economy design violates 'No randomized premium rewards without published drop rates and a pity timer'. Approval is blocked until this is resolved."
 4. AskUserQuestion presented with resolution options before season plan approval is offered
 5. Skill does NOT issue a COMPLETE verdict or write output documents until the ethics violation is resolved or explicitly waived by the user

@@ -82,7 +96,7 @@ season plan requiring user approval before handoff to production.
 - [ ] AskUserQuestion is used to surface the violation and offer resolution options (revise economy design, override with documented rationale, cancel)
 - [ ] Output documents are NOT written while the violation is unresolved
 - [ ] If user chooses to revise: skill re-spawns economy-designer to produce a corrected design before returning to Phase 7 review
- [ ] Verdict: COMPLETE is only issued after the ethics flag is cleared
+- [ ] Verdict: COMPLETE is only issued after the ethics flag is cleared; Cancel ends with Verdict: BLOCKED

 ---

@@ -94,14 +108,14 @@ season plan requiring user approval before handoff to production.
 **Input:** `/team-live-ops` (no argument)

 **Expected behavior:**
-1. Phase 1: No argument detected
-2. Outputs: "Usage: `/team-live-ops [season name or event description]` — Provide the name or description of the season or live event to plan."
+1. No argument detected
+2. Outputs: "Usage: `/team-live-ops [season name or event description] [--review full|lean|solo]` — Provide the name or description of the season or live event to plan."
 3. Skill exits immediately without spawning any subagents

 **Assertions:**
 - [ ] Skill does NOT guess a season name or fabricate a scope
- [ ] Error message includes the correct usage format with the argument-hint
- [ ] No Task calls are issued before the argument check fails
+- [ ] Usage message shows the full argument-hint: `/team-live-ops [season name or event description] [--review full|lean|solo]`
+- [ ] No Agent calls are issued before the argument check fails
 - [ ] No files are read or written

 ---
@@ -109,6 +123,7 @@ season plan requiring user approval before handoff to production.
 ### Case 4: Parallel Phase Validation — Phases 3 and 4 run simultaneously

 **Fixture:**
+- Resolved config block: `team.size: small`, `automation: collaborative`
 - All standard live-ops fixtures present
 - Phase 1 (season brief) and Phase 2 (narrative framing) already approved
 - Phase 3 (economy-designer) and Phase 4 (analytics-engineer) inputs are independent of each other
@@ -116,13 +131,13 @@ season plan requiring user approval before handoff to production.
 **Input:** `/team-live-ops "Season 1: The First Thaw"` (observed at Phase 3/4 transition)

 **Expected behavior:**
-1. After Phase 2 is approved by the user, the orchestrator issues both Task calls (economy-designer and analytics-engineer) before awaiting either result
+1. After Phase 2 is approved by the user, the orchestrator issues both Agent calls (economy-designer and analytics-engineer) before awaiting either result
 2. Both agents receive the season brief as context; analytics-engineer does NOT wait for economy-designer output to begin
 3. Economy-designer output and analytics-engineer output are collected together before Phase 5 begins
 4. If one of the two parallel agents blocks, the other continues; a partial result is reported

 **Assertions:**
- [ ] Both Task calls for Phase 3 and Phase 4 are issued before either result is awaited — they are not sequential
+- [ ] Both Agent calls for Phase 3 and Phase 4 are issued before either result is awaited — they are not sequential
 - [ ] Analytics-engineer prompt does NOT include economy-designer output as a required input (the inputs are independent)
 - [ ] If economy-designer blocks but analytics-engineer succeeds, analytics output is preserved and the block is surfaced via AskUserQuestion
 - [ ] Phase 5 does not begin until BOTH Phase 3 and Phase 4 results are collected
@@ -140,7 +155,7 @@ season plan requiring user approval before handoff to production.
 **Input:** `/team-live-ops "Season 4: Desert Heat"`

 **Expected behavior:**
-1. Phases 1–4 proceed; economy-designer and analytics-engineer are given the ethics policy path but it is absent
+1. Phases 1–6 proceed normally
 2. Phase 7: Orchestrator attempts to run ethics review; detects that `design/live-ops/ethics-policy.md` is missing
 3. Phase 7 summary includes a gap flag: "ETHICS REVIEW SKIPPED: `design/live-ops/ethics-policy.md` not found. Economy design was not reviewed against an ethics policy. Recommend creating one before production begins."
 4. Skill still completes the season plan and reaches COMPLETE verdict, but the gap is prominently flagged in the output and in the season design document
@@ -158,21 +173,23 @@ season plan requiring user approval before handoff to production.

 ## Protocol Compliance

- [ ] `AskUserQuestion` used at every phase transition — user approves before the next phase begins
- [ ] Phases 3 and 4 are always spawned in parallel, not sequentially
- [ ] File Write Protocol: orchestrator never calls Write/Edit directly — all writes are delegated to sub-agents
- [ ] Each output document gets its own "May I write to [path]?" ask from the relevant sub-agent
+- [ ] At the default `team.size: individual`, the run opens with an `Active set (team.size: individual): live-ops-designer + economy-designer` line and a `Not spawned this run:` line naming analytics-engineer, community-manager, narrative-director and writer — before any agent is spawned
+- [ ] In `collaborative` mode, `AskUserQuestion` used at every phase transition — user approves before the next phase begins
+- [ ] When analytics-engineer is in the active set (`small` or `studio`), Phases 3 and 4 are spawned in parallel, not sequentially
+- [ ] Sub-agents write only to paths the orchestrator named, under the bounded exception; the `design/live-ops/` documents are written by the orchestrator after one `AskUserQuestion` "May I write the season plan…" approval
+- [ ] A phase whose named artifact is missing on disk is treated as failed, not done
 - [ ] Ethics review in Phase 7 always references the ethics policy file path explicitly
 - [ ] Error recovery: any BLOCKED agent is surfaced immediately with AskUserQuestion options (skip / retry / stop)
 - [ ] Partial reports are produced if any phase blocks — work is never discarded
 - [ ] Verdict: COMPLETE only after user approves the consolidated season plan; BLOCKED if any unresolved ethics violation exists
- [ ] Next steps always include `/design-review`, `/sprint-plan`, and `/team-release`
+- [ ] Next steps after a COMPLETE plan include `/design-review`, `/sprint-plan`, and `/team-release`; a run that ends BLOCKED on an ethics flag names the revision and re-run instead

 ---

 ## Coverage Notes

- Phase 5 parallel spawning (narrative-director + writer) follows the same pattern as Phases 3/4 but is not separately tested here — it uses the same parallel Task protocol validated in Case 4.
+- Phase 5 parallel spawning (narrative-director + writer) follows the same pattern as Phases 3/4 but is not separately tested here — it uses the same parallel Agent protocol validated in Case 4.
 - The "economy-rules.md absent" edge case is not separately tested — it would surface as a BLOCKED result from economy-designer and follow the standard error recovery path tested implicitly in Case 4.
 - The full content writing pipeline (Phase 5 output validation) is validated implicitly by the Case 1 happy path consolidated summary check.
 - Community manager communication calendar format (pre-launch, launch day, mid-season, final week) is validated implicitly by Case 1; no separate edge case is needed.
+- Cases 2 and 5 depend only on economy-designer and the Phase 7 review, both of which run at every `team.size`.
@@ -3,14 +3,22 @@
 ## Skill Summary

 Orchestrates the narrative team through a five-phase pipeline: narrative direction
-(narrative-director) → world foundation + dialogue drafting (world-builder and writer
-in parallel) → level narrative integration (level-designer) → consistency review
-(narrative-director) → polish + localization compliance (writer, localization-lead,
-and world-builder in parallel). Uses `AskUserQuestion` at each phase transition to
-present proposals as selectable options. Produces a narrative summary report and
-delivers narrative documents via subagents that each enforce the "May I write?"
-protocol. Verdict is COMPLETE when all phases succeed, or BLOCKED when a dependency
-is unresolved.
+(narrative-director) → world foundation, dialogue drafting and visual direction
+(world-builder, writer and art-director in parallel) → level narrative integration
+(level-designer) → consistency review (narrative-director) → polish + localization
+compliance (writer, localization-lead, and world-builder in parallel). Phase 0
+resolves `review_mode`, `automation` and `team.size` and the skill announces the
+active set before Phase 1 — at the default `individual` only writer is spawned
+(narrative-director only on an explicit pillar conflict), `small` adds
+narrative-director, plus localization-lead and world-builder when `review_mode` is
+`full`, and `studio` activates every narrative agent whatever the review mode. Each agent drafts to a concrete path
+under `production/narrative/[content-slug]/` named in the skill's path table;
+Phase 4 runs the ND-CONSISTENCY gate; the orchestrator writes the final documents
+to `design/narrative/` after one approval. Uses
+`AskUserQuestion` at each phase transition. Produces a narrative summary report.
+Verdict is COMPLETE when all phases succeed — `COMPLETE — consistency NOT ASSESSED
+([input])` when the ND-CONSISTENCY review could not assess — or BLOCKED when a
+dependency is unresolved.

 ---

@@ -20,12 +28,15 @@ is unresolved.
 - [ ] Has ≥2 phase headings
 - [ ] Contains verdict keywords: COMPLETE, BLOCKED
 - [ ] Contains "File Write Protocol" section
- [ ] File writes are delegated to sub-agents — orchestrator does not write files directly
- [ ] Sub-agents enforce "May I write to [path]?" before any write
+- [ ] Sub-agents write drafts under `production/narrative/[content-slug]/`; the orchestrator writes only the final `design/narrative/` documents, after one "May I write" approval
+- [ ] Names a concrete draft path per agent (including level-designer and localization-lead) and the final `design/narrative/` document each design artifact becomes — localization-lead's review is not one, and stays in `production/`
+- [ ] Every agent prompt ends with the return contract: path written, ≤5-bullet summary, BLOCKED/CONCERNS items one line each
+- [ ] Defines a phase gate as a decision point the pipeline itself lists, whatever the `automation` mode, and claims no director spawn at phase gates
 - [ ] Has a next-step handoff at the end (references `/design-review`, `/localize extract`, `/dev-story`)
- [ ] Error Recovery Protocol section is present
- [ ] `AskUserQuestion` is used at phase transitions before proceeding
- [ ] Phase 2 explicitly spawns world-builder and writer in parallel
+- [ ] Error Recovery Protocol section is present: verify a named artifact is on disk, surface BLOCKED immediately, always produce a partial report, full procedure in `.claude/docs/error-recovery-protocol.md`
+- [ ] `AskUserQuestion` is used at phase transitions before proceeding (`collaborative` mode)
+- [ ] Phase 0 resolves `team.size`, and the skill requires a one-line active-set announcement before Phase 1
+- [ ] Phase 2 explicitly spawns world-builder, writer and art-director in parallel
 - [ ] Phase 5 explicitly spawns writer, localization-lead, and world-builder in parallel

 ---
@@ -35,6 +46,7 @@ is unresolved.
 ### Case 1: Happy Path — All five phases complete, narrative doc delivered

 **Fixture:**
+- Resolved config block: `team.size: studio`, `automation: collaborative`
 - A game concept and GDD exist for the target feature (e.g., `design/gdd/faction-intro.md`)
 - Character voice profiles exist (e.g., `design/narrative/characters/`)
 - Existing lore entries exist for cross-reference (e.g., `design/narrative/lore/`)
@@ -43,27 +55,32 @@ is unresolved.
 **Input:** `/team-narrative faction introduction cutscene for the Ironveil faction`

 **Expected behavior:**
-1. Phase 1: narrative-director is spawned; outputs a narrative brief defining the story beat, characters involved, emotional tone, and lore dependencies
-2. `AskUserQuestion` presents the narrative brief; user approves before Phase 2 begins
-3. Phase 2: world-builder and writer are spawned in parallel; world-builder produces lore entries for the Ironveil faction; writer drafts dialogue lines using character voice profiles
-4. `AskUserQuestion` presents world foundation and dialogue drafts; user approves before Phase 3 begins
-5. Phase 3: level-designer is spawned; produces environmental storytelling layout, trigger placement, and pacing plan
-6. `AskUserQuestion` presents level narrative plan; user approves before Phase 4 begins
-7. Phase 4: narrative-director reviews all dialogue against voice profiles, verifies lore consistency, confirms pacing; approves or flags issues
-8. `AskUserQuestion` presents review results; user approves before Phase 5 begins
-9. Phase 5: writer, localization-lead, and world-builder are spawned in parallel; writer performs final self-review; localization-lead validates i18n compliance; world-builder finalizes canon levels
-10. Final summary report is presented; subagent asks "May I write the narrative document to [path]?" before writing
-11. Verdict: COMPLETE
+1. Before any spawn, one line announces the active set for `team.size: studio`
+2. Phase 1: narrative-director is spawned; writes a narrative brief draft to `production/narrative/[content-slug]/brief.md` defining the story beat, characters involved, emotional tone, and lore dependencies
+3. `AskUserQuestion` presents the narrative brief; user approves before Phase 2 begins
+4. Phase 2: world-builder, writer and art-director are spawned in parallel; world-builder drafts Ironveil lore entries, writer drafts dialogue using character voice profiles, and art-director drafts visual direction — each under `production/narrative/[content-slug]/`
+5. Phase gate: all three Phase 2 outputs are collected, then `AskUserQuestion` presents the lore, dialogue and visual direction summaries; user approves before Phase 3 begins
+6. Phase 3: level-designer is spawned; produces environmental storytelling layout, trigger placement, and pacing plan
+7. `AskUserQuestion` presents level narrative plan; user approves before Phase 4 begins
+8. Phase 4: narrative-director is spawned with the ND-CONSISTENCY gate; reviews voices, lore and pacing and returns APPROVE
+9. `AskUserQuestion` presents review results; user approves before Phase 5 begins
+10. Phase 5: writer, localization-lead, and world-builder are spawned in parallel; writer performs final self-review; localization-lead validates i18n compliance; world-builder finalizes canon levels
+11. The orchestrator lists the final documents and asks once, "May I write these [N] narrative documents to `design/narrative/`?"; on approval it writes them
+12. Final summary report is presented
+13. Verdict: COMPLETE

 **Assertions:**
+- [ ] Active-set line naming `team.size: studio` appears before the first agent is spawned
 - [ ] narrative-director is spawned in Phase 1 before any other agents
 - [ ] `AskUserQuestion` appears after Phase 1 output and before Phase 2 launch
- [ ] world-builder and writer Task calls are issued simultaneously in Phase 2 (not sequentially)
+- [ ] world-builder, writer and art-director Agent calls are issued simultaneously in Phase 2 (not sequentially)
 - [ ] level-designer is not launched until Phase 2 `AskUserQuestion` is approved
- [ ] narrative-director is re-spawned in Phase 4 for consistency review
+- [ ] narrative-director is re-spawned in Phase 4 using gate ND-CONSISTENCY — in every review mode, since it is this pipeline's own review and `review_mode` never skips it — and its APPROVE / CONCERNS / REJECT verdict decides whether Phase 5 starts
 - [ ] Phase 5 spawns all three agents (writer, localization-lead, world-builder) simultaneously
+- [ ] Each agent prompt names its draft path from the skill's path table
+- [ ] Nothing is written under `design/narrative/` before the single "May I write" approval
 - [ ] Summary report includes: narrative brief status, lore entries created/updated, dialogue lines written, level narrative integration points, consistency review results
- [ ] No files are written by the orchestrator directly
+- [ ] The orchestrator writes nothing except the approved final documents
 - [ ] Verdict is COMPLETE after delivery

 ---
@@ -71,6 +88,7 @@ is unresolved.
 ### Case 2: Lore Contradiction Found — world-builder finds conflict before writer proceeds

 **Fixture:**
+- Resolved config block: `team.size: studio`, `automation: collaborative`
 - Existing lore entry at `design/narrative/lore/ironveil-history.md` states the Ironveil faction was founded 200 years ago
 - The new narrative brief (from Phase 1) states the Ironveil were founded 50 years ago
 - The writer has been spawned in parallel with the world-builder in Phase 2
@@ -83,11 +101,11 @@ is unresolved.
 3. world-builder returns BLOCKED with reason: "Lore contradiction found — founding date conflicts with `design/narrative/lore/ironveil-history.md`"
 4. Orchestrator surfaces the contradiction immediately: "world-builder: BLOCKED — Lore contradiction: founding date in narrative brief (50 years ago) conflicts with existing canon (200 years ago in `ironveil-history.md`)"
 5. Orchestrator assesses dependency: the writer's dialogue depends on canon lore — the writer's draft cannot be finalized without resolving the contradiction
-6. `AskUserQuestion` presents options:
-   - Revise the narrative brief to match existing canon (200 years ago)
-   - Update the existing lore entry to reflect the new canon (50 years ago)
+6. `AskUserQuestion` presents the error-recovery options:
+   - Skip world-builder and note the gap in the final report
+   - Retry with narrower scope (e.g., world-builder works against the canon the user confirms)
   - Stop here and resolve the contradiction in the lore docs first
-7. Writer output is preserved but flagged as pending canon resolution — work is not discarded
+7. Writer output is preserved in the partial report — work is not discarded
 8. Orchestrator does NOT proceed to Phase 3 until the contradiction is resolved or user explicitly chooses to skip

 **Assertions:**
@@ -95,7 +113,7 @@ is unresolved.
 - [ ] Orchestrator does not silently resolve the contradiction by picking one version
 - [ ] `AskUserQuestion` presents at least 3 options including "stop and resolve first"
 - [ ] Writer's draft output is preserved in the partial report, not discarded
- [ ] Phase 3 (level-designer) is not launched until the user resolves the contradiction
+- [ ] Phase 3 (level-designer) is not launched until the user resolves the contradiction or explicitly chooses to skip world-builder
 - [ ] Verdict is BLOCKED (not COMPLETE) if the user stops to resolve the contradiction

 ---
@@ -109,43 +127,44 @@ is unresolved.

 **Expected behavior:**
 1. Skill detects no argument is provided
-2. Outputs usage guidance: e.g., "Usage: `/team-narrative [narrative content description]` — describe the story content, scene, or narrative area to work on (e.g., `boss encounter cutscene`, `faction intro dialogue`, `tutorial narrative`)"
+2. Outputs usage guidance: e.g., "Usage: `/team-narrative [narrative content description] [--review full|lean|solo]` — describe the story content, scene, or narrative area to work on (e.g., `boss encounter cutscene`, `faction intro dialogue`, `tutorial narrative`)"
 3. Skill exits without spawning any agents

 **Assertions:**
 - [ ] Skill does NOT spawn any agents when no argument is provided
- [ ] Usage message includes the correct invocation format with an argument example
+- [ ] Usage message shows the full argument-hint — `/team-narrative [narrative content description] [--review full|lean|solo]` — and an argument example
 - [ ] Skill does NOT attempt to guess or infer a narrative topic from project files
 - [ ] No `AskUserQuestion` is used — output is direct guidance

 ---

-### Case 4: Localization Compliance — localization-lead flags a non-translatable string
+### Case 4: Localization Compliance — localization-lead blocks on a non-translatable string

 **Fixture:**
+- Resolved config block: `team.size: studio`, `automation: collaborative`
 - Phases 1–4 complete successfully
 - Phase 5 begins; writer and world-builder complete without issues
- localization-lead finds a dialogue line that uses a hardcoded formatted date string (e.g., `"On March 12th, Year 3"`) that cannot survive locale-specific translation without a locale-aware formatter
+- localization-lead finds a dialogue line that uses a hardcoded formatted date string (e.g., `"On March 12th, Year 3"`) that cannot survive locale-specific translation without a locale-aware formatter, and returns it as a BLOCKED item in its return contract

 **Input:** `/team-narrative ironveil faction introduction cutscene` (Phase 5 scenario)

 **Expected behavior:**
 1. Phase 5 spawns writer, localization-lead, and world-builder in parallel
-2. localization-lead completes its review and flags: "String key `dialogue.ironveil.intro.003` contains a hardcoded date format (`March 12th, Year 3`) that will not localize correctly — requires a locale-aware date placeholder"
-3. Orchestrator surfaces the localization blocker in the summary report
-4. The localization issue is labeled as BLOCKING in the final report (not advisory)
-5. `AskUserQuestion` presents options:
-   - Fix the string now (writer revises the line)
-   - Note the gap and deliver the narrative doc with the issue flagged
+2. localization-lead returns BLOCKED: "String key `dialogue.ironveil.intro.003` contains a hardcoded date format (`March 12th, Year 3`) that will not localize correctly — requires a locale-aware date placeholder"
+3. Orchestrator surfaces it immediately: "localization-lead: BLOCKED — [reason with the string key]"
+4. writer's and world-builder's Phase 5 outputs are kept in the partial report
+5. `AskUserQuestion` presents the error-recovery options:
+   - Skip and note the gap in the final report (deliver with the string flagged)
+   - Retry with narrower scope (e.g., the writer revises that one line, then localization-lead re-checks it)
   - Stop and resolve before finalizing
-6. If the user chooses to proceed with the issue flagged, verdict is COMPLETE with noted localization debt; if user stops, verdict is BLOCKED
+6. If the user skips, the final summary lists the unfixed string key among its unresolved items; if the user stops, the verdict is `BLOCKED — [reason]`

 **Assertions:**
 - [ ] localization-lead is spawned in Phase 5 simultaneously with writer and world-builder
 - [ ] Hardcoded date format is identified as a localization blocker (not silently passed)
- [ ] The specific string key and reason are included in the issue report
- [ ] `AskUserQuestion` offers the option to fix now vs. flag and proceed
- [ ] Verdict notes the localization debt if the user proceeds without fixing
+- [ ] The specific string key and reason are included in the surfaced BLOCKED message
+- [ ] `AskUserQuestion` offers skip-and-note-gap, retry, and stop options
+- [ ] If the user proceeds without fixing, the final report names the unfixed string key; if the user stops, the verdict is BLOCKED
 - [ ] Skill does NOT automatically rewrite the offending line without user approval

 ---
@@ -153,23 +172,24 @@ is unresolved.
 ### Case 5: Writer Blocked — Missing character voice profiles

 **Fixture:**
+- Resolved config block: `team.size: studio`, `automation: collaborative`
 - Phase 1 narrative-director produces a narrative brief referencing two characters: Commander Varek and Advisor Selene
 - No character voice profiles exist in `design/narrative/characters/` for either character
- Phase 2 begins; world-builder proceeds normally
+- Phase 2 begins; world-builder and art-director proceed normally

 **Input:** `/team-narrative ironveil surrender negotiation scene`

 **Expected behavior:**
 1. Phase 1 completes; narrative brief lists Commander Varek and Advisor Selene as characters
-2. Phase 2: writer is spawned in parallel with world-builder
+2. Phase 2: writer is spawned in parallel with world-builder and art-director
 3. writer returns BLOCKED: "Cannot produce dialogue — no voice profiles found for Commander Varek or Advisor Selene in `design/narrative/characters/`. Voice profiles required to match character tone and speech patterns."
 4. Orchestrator surfaces the blocker immediately: "writer: BLOCKED — Missing prerequisite: character voice profiles for Commander Varek and Advisor Selene"
 5. world-builder output is preserved; partial report is produced with lore entries
-6. `AskUserQuestion` presents options:
-   - Create voice profiles first (redirects to the narrative-director or design workflow)
-   - Provide minimal voice direction inline and retry the writer with that context
+6. `AskUserQuestion` presents the error-recovery options:
+   - Skip writer and note the gap in the final report
+   - Retry with narrower scope (e.g., minimal voice direction supplied inline)
   - Stop here and create voice profiles before proceeding
-7. Orchestrator does NOT proceed to Phase 3 (level-designer) without writer output
+7. Orchestrator does NOT proceed to Phase 3 (level-designer) without writer output unless the user explicitly chooses to skip

 **Assertions:**
 - [ ] Writer block is surfaced before Phase 3 begins
@@ -183,13 +203,16 @@ is unresolved.

 ## Protocol Compliance

- [ ] `AskUserQuestion` is used after every phase output before the next phase launches
- [ ] Parallel spawning: Phase 2 (world-builder + writer) and Phase 5 (writer + localization-lead + world-builder) issue all Task calls before waiting for results
- [ ] No files are written by the orchestrator directly — all writes are delegated to sub-agents
- [ ] Each sub-agent enforces the "May I write to [path]?" protocol before any write
+- [ ] At the default `team.size: individual`, the run opens with `Active set (team.size: individual): writer.` and a `Not spawned this run:` line naming narrative-director, world-builder, art-director, level-designer and localization-lead, consulted through writer — before any agent is spawned
+- [ ] In `collaborative` mode, `AskUserQuestion` is used after every phase output before the next phase launches
+- [ ] Parallel spawning: Phase 2 (world-builder + writer + art-director) and Phase 5 (writer + localization-lead + world-builder) issue all Agent calls before waiting for results
+- [ ] No write under `design/` happens without a "May I write" approval — `design/` is outside the bounded exception (`production/`, `docs/`, `tests/`)
+- [ ] At `team.size: individual`, Phase 4 does not spawn narrative-director; the output says "ND-CONSISTENCY not run — narrative-director is not active at `team.size: individual`; consistency self-checked by writer." and never presents the writer's self-check as the gate's verdict
+- [ ] An ND-CONSISTENCY `NOT ASSESSED [missing input]` answer is never treated as APPROVE: the missing input is named, then either supplied and the gate re-run, or `ND-CONSISTENCY: NOT ASSESSED — [input]` is carried into the report's consistency review results and the verdict reads `COMPLETE — consistency NOT ASSESSED ([input])`, never a plain COMPLETE
+- [ ] A phase whose named artifact is missing on disk is treated as failed, not done
 - [ ] BLOCKED status from any agent is surfaced immediately — not silently skipped
 - [ ] A partial report is always produced when some agents complete and others block
- [ ] Verdict is exactly COMPLETE or BLOCKED — no other verdict values used
+- [ ] Verdict is exactly COMPLETE, `COMPLETE — consistency NOT ASSESSED ([input])` or BLOCKED — no other verdict values used
 - [ ] Next Steps handoff references `/design-review`, `/localize extract`, and `/dev-story`

 ---
@@ -200,10 +223,11 @@ is unresolved.
  validated implicitly by Case 1. Separate edge cases are not needed for these phases as
  their failure modes follow the standard Error Recovery Protocol.
 - The "Retry with narrower scope" and "Skip this agent" resolution paths from the Error
-  Recovery Protocol are not separately tested — they follow the same `AskUserQuestion`
-  + partial-report pattern validated in Cases 2 and 5.
- Localization concerns that are advisory (e.g., German/Finnish +30% expansion warnings)
-  vs. blocking (hardcoded formats) are distinguished in Case 4; advisory-only scenarios
-  follow the same pattern but do not change the verdict.
+  Recovery Protocol are not separately walked to completion — Cases 2, 4 and 5 check that
+  they are offered.
+- Advisory localization concerns (e.g., German/Finnish +30% expansion warnings) are not
+  given a case; Case 4 covers only a concern the localization-lead returns as BLOCKED.
 - The writer's "all lines under 120 characters" and "string keys not raw strings" checks
  in Phase 5 are covered implicitly by Case 4's localization compliance scenario.
+- The `small` active set (review_mode-dependent localization-lead and world-builder) is not
+  given its own case.
@@ -3,13 +3,25 @@
 ## Skill Summary

 Orchestrates the polish team through a six-phase pipeline: performance assessment
-(performance-analyst) → optimization (performance-analyst, optionally with
-engine-programmer when engine-level root causes are found) → visual polish
+(performance-analyst, whose report carries the optimisation list with an owner per
+item) → optimization (the list implemented by its owners in the active set —
+engine-programmer for engine-level root causes, tools-programmer for a content
+tool; performance-analyst writes no game code) → visual polish
 (technical-artist, parallel with Phase 2) → audio polish (sound-designer, parallel
 with Phase 2) → hardening (qa-tester) → sign-off (orchestrator collects all results
-and issues READY FOR RELEASE or NEEDS MORE WORK). Uses `AskUserQuestion` at each
-phase transition. Engine-programmer is spawned conditionally only when Phase 1
-identifies engine-level root causes. Verdict is READY FOR RELEASE or NEEDS MORE WORK.
+and issues READY FOR RELEASE, NOT ASSESSED or NEEDS MORE WORK — NOT ASSESSED when a
+budget is uncommitted or a phase did not run). Phase 0 resolves `review_mode`,
+`automation` and `team.size` and the skill announces the active set before Phase 1
+— the default `individual` spawns performance-analyst + technical-artist only, so
+no programmer is active and the report names the optimisation list as handed to
+`/dev-story`; `small` adds sound-designer, qa-tester and engine-programmer (the full
+pipeline); `studio` keeps that set and adds an adversarial pass. Each agent writes a
+date-stamped report to a named path under `production/polish/` under the bounded
+write exception (no per-write prompt), and the orchestrator states that nothing
+reads `production/polish/` yet. The code, shader, audio and asset changes of
+Phases 2–4 are outside that exception: one ask covers the whole set. Uses
+`AskUserQuestion` at each phase transition. Engine-programmer is spawned
+conditionally only when Phase 1 identifies engine-level root causes.

 ---

@@ -17,16 +29,22 @@ identifies engine-level root causes. Verdict is READY FOR RELEASE or NEEDS MORE

 - [ ] Has required frontmatter fields: `name`, `description`, `argument-hint`, `user-invocable`, `allowed-tools`
 - [ ] Has ≥2 phase headings
- [ ] Contains verdict keywords: READY FOR RELEASE, NEEDS MORE WORK
+- [ ] Contains verdict keywords: READY FOR RELEASE, NOT ASSESSED, NEEDS MORE WORK — and states that NOT ASSESSED ranks above READY FOR RELEASE and below NEEDS MORE WORK
 - [ ] Contains "File Write Protocol" section
 - [ ] File writes are delegated to sub-agents — orchestrator does not write files directly
- [ ] Sub-agents enforce "May I write to [path]?" before any write
+- [ ] Names a destination per agent under `production/polish/`: `[area]-report-[date].md` (performance-analyst), `[area]-render-notes-[date].md` (technical-artist), `[area]-engine-fixes-[date].md` (engine-programmer), `[area]-tool-fixes-[date].md` (tools-programmer), `[area]-audio-notes-[date].md` (sound-designer), `[area]-verification-[date].md` (qa-tester)
+- [ ] Sub-agents write those named `production/` paths without a per-write prompt (bounded exception), and must ask for any write outside it; implementation files (code, shaders, audio, assets) are outside it — each agent lists the files it will create or change, and the skill asks once for the set before any is written — one ask for the whole Phase 2–4 set, never one per phase
+- [ ] The `small` and `studio` sets include `engine-programmer`; at `individual` no programmer is active and the report names the optimisation list as handed to `/dev-story`
+- [ ] Defines a phase gate as a decision point the pipeline itself lists, whatever the `automation` mode, and claims no director spawn at phase gates
 - [ ] Has a next-step handoff at the end (references `/release-checklist`, `/sprint-plan update`, `/gate-check`)
- [ ] Error Recovery Protocol section is present
- [ ] `AskUserQuestion` is used at phase transitions before proceeding
+- [ ] Error Recovery Protocol section is present: verify a named artifact is on disk, surface BLOCKED immediately, always produce a partial report, full procedure in `.claude/docs/error-recovery-protocol.md`
+- [ ] `AskUserQuestion` is used at phase transitions before proceeding (`collaborative` mode)
+- [ ] Phase 0 resolves `team.size`, and the skill requires a one-line active-set announcement before Phase 1
 - [ ] Phase 3 (visual polish) and Phase 4 (audio polish) are explicitly run in parallel with Phase 2
+- [ ] Phase 1's report carries the optimisation list with an owner per item; performance-analyst writes no game code in any phase
 - [ ] engine-programmer is conditionally spawned in Phase 2 only when Phase 1 identifies engine-level root causes
 - [ ] Phase 6 sign-off compares metrics against budgets before issuing verdict
+- [ ] Phase 6 lists every remaining issue with its severity, the measured gap where there is one (e.g. "3 ms over budget") and a recommendation

 ---

@@ -35,8 +53,9 @@ identifies engine-level root causes. Verdict is READY FOR RELEASE or NEEDS MORE
 ### Case 1: Happy Path — Full pipeline completes, READY FOR RELEASE verdict

 **Fixture:**
+- Resolved config block: `team.size: small`, `automation: collaborative`
 - Feature exists and is functionally complete (e.g., `combat` system)
- Performance budgets are defined in technical-preferences.md (e.g., target 60fps, 16ms frame budget)
+- Performance budgets are defined in `project.yaml` (`performance.target_framerate: 60`, `performance.frame_budget_ms: 16.6`, `performance.draw_call_limit: 2000`, `performance.memory_ceiling_mb: 2048`)
 - No frame budget violations exist before polishing begins
 - No audio events are missing; VFX assets are complete
 - No regressions are introduced by polish changes
@@ -44,27 +63,34 @@ identifies engine-level root causes. Verdict is READY FOR RELEASE or NEEDS MORE
 **Input:** `/team-polish combat`

 **Expected behavior:**
-1. Phase 1: performance-analyst is spawned; profiles the combat system, measures frame budget, checks memory usage; output: performance report showing all metrics within budget, no violations
-2. `AskUserQuestion` presents performance report; user approves before Phases 2, 3, and 4 begin
-3. Phase 2: performance-analyst applies minor optimizations (e.g., draw call batching); no engine-programmer needed (no engine-level root causes identified)
-4. Phases 3 and 4 are launched in parallel alongside Phase 2:
-   - Phase 3: technical-artist reviews VFX for quality, optimizes particle systems, adds screen shake and visual juice
-   - Phase 4: sound-designer reviews audio events for completeness, checks mix levels, adds ambient audio layers
-5. All three parallel phases complete; `AskUserQuestion` presents results; user approves before Phase 5 begins
-6. Phase 5: qa-tester runs edge case tests, soak tests, stress tests, and regression tests; all pass
-7. `AskUserQuestion` presents test results; user approves before Phase 6
-8. Phase 6: orchestrator collects all results; compares before/after performance metrics against budgets; all metrics pass
-9. Subagent asks "May I write the polish report to `production/qa/evidence/polish-combat-[date].md`?" before writing
-10. Verdict: READY FOR RELEASE
+1. Before any spawn, one line announces the active set for `team.size: small` (the full pipeline)
+2. Phase 1: performance-analyst is spawned; profiles the combat system, measures frame budget, checks memory usage; writes `production/polish/combat-report-[date].md` showing all metrics within budget
+3. `AskUserQuestion` presents performance report; user approves before Phases 2, 3, and 4 begin
+4. Phase 2: the report's optimisation list holds only minor rendering items (e.g., draw call batching), owned by technical-artist, so they join its Phase 3 brief; no engine-level root cause was identified, so engine-programmer is not spawned; performance-analyst changes no code
+5. Phases 3 and 4 are launched in parallel alongside Phase 2:
+   - Phase 3: technical-artist reviews VFX for quality, optimizes particle systems, adds screen shake and visual juice; writes `production/polish/combat-render-notes-[date].md`
+   - Phase 4: sound-designer reviews audio events for completeness, checks mix levels, adds ambient audio layers; writes `production/polish/combat-audio-notes-[date].md`
+   - The agents changing shaders, VFX or assets first list the files; one `AskUserQuestion` covers the whole Phase 2–4 set, and nothing is edited before the yes
+6. All three parallel phases complete; `AskUserQuestion` presents results; user approves before Phase 5 begins
+7. Phase 5: qa-tester runs edge case tests, soak tests, stress tests, and regression tests; all pass; writes `production/polish/combat-verification-[date].md`
+8. `AskUserQuestion` presents test results; user approves before Phase 6
+9. Phase 6: orchestrator collects all results; compares before/after performance metrics against budgets; all metrics pass
+10. The report says the `production/polish/` files are a record that nothing in the repo reads yet
+11. Verdict: READY FOR RELEASE

 **Assertions:**
+- [ ] Active-set line naming `team.size: small` appears before the first agent is spawned
 - [ ] performance-analyst is spawned first in Phase 1 before any other agents
 - [ ] `AskUserQuestion` appears after Phase 1 output and before Phases 2/3/4 launch
- [ ] Phases 3 and 4 Task calls are issued at the same time as Phase 2 (not after Phase 2 completes)
+- [ ] Phases 3 and 4 Agent calls are issued at the same time as Phase 2 (not after Phase 2 completes)
 - [ ] engine-programmer is NOT spawned when Phase 1 finds no engine-level root causes
+- [ ] performance-analyst edits no code, shader or asset in any phase
+- [ ] Implementation files of Phases 2–4 are listed by each agent and asked for in one `AskUserQuestion` for the whole set — not once per phase — before any is edited
 - [ ] qa-tester (Phase 5) is not launched until the parallel phases complete and user approves
+- [ ] Each agent writes to its named `production/polish/[area]-…-[date].md` path without a per-write prompt, and the orchestrator confirms the file exists before treating the phase as done
 - [ ] Phase 6 verdict is based on comparison of metrics against defined budgets
 - [ ] Summary report includes: before/after performance metrics, visual polish changes, audio polish changes, test results
+- [ ] Summary states that nothing reads `production/polish/` yet
 - [ ] No files are written by the orchestrator directly
 - [ ] Verdict is READY FOR RELEASE

@@ -73,22 +99,23 @@ identifies engine-level root causes. Verdict is READY FOR RELEASE or NEEDS MORE
 ### Case 2: Performance Blocker — Frame budget violation cannot be fully resolved

 **Fixture:**
+- Resolved config block: `team.size: small`, `automation: collaborative`
 - Feature being polished: `particle-storm` VFX system
 - Phase 1 identifies a frame budget violation: particle-storm costs 12ms on target hardware (budget is 6ms for this system)
- Phase 2 performance-analyst applies optimizations reducing cost to 9ms — still over the 6ms budget
+- Phase 1's optimisation list assigns the particle work to technical-artist and an engine-level particle-update hot path to engine-programmer; after both are applied the cost is 9ms — still over the 6ms budget
 - Phase 2 cannot fully resolve the violation without a fundamental design change

 **Input:** `/team-polish particle-storm`

 **Expected behavior:**
-1. Phase 1: performance-analyst identifies the 12ms frame cost vs. 6ms budget; reports "FRAME BUDGET VIOLATION: particle-storm costs 12ms, budget is 6ms"
+1. Phase 1: performance-analyst identifies the 12ms frame cost vs. 6ms budget; reports "FRAME BUDGET VIOLATION: particle-storm costs 12ms, budget is 6ms", with an optimisation list naming each item's owner
 2. `AskUserQuestion` presents the violation; user chooses to proceed with optimization attempt
-3. Phase 2: performance-analyst applies optimizations; achieves 9ms — reduced but still over budget; reports "Optimization reduced cost to 9ms (was 12ms) — 3ms over budget. No further gains achievable without design changes."
+3. Phase 2: engine-programmer implements the engine-level item and technical-artist the particle items (after the one ask for the set); the re-profile reads 9ms — reduced but still over budget: "Optimization reduced cost to 9ms (was 12ms) — 3ms over budget. No further gains achievable without design changes."
 4. Phases 3 and 4 run in parallel with Phase 2 (visual and audio polish)
 5. Phase 5: qa-tester runs regression and edge case tests; all pass
 6. Phase 6: orchestrator collects results; frame budget violation (9ms vs 6ms budget) remains unresolved
 7. Verdict: NEEDS MORE WORK
-8. Report lists the specific unresolved issue: "particle-storm frame cost (9ms) exceeds budget (6ms) by 3ms — requires design scope reduction or budget renegotiation"
+8. Report lists the specific unresolved issue with severity: "particle-storm frame cost (9ms) exceeds budget (6ms) by 3ms — requires design scope reduction or budget renegotiation"
 9. Next Steps: schedule the remaining issue in `/sprint-plan update`; re-run `/team-polish` after fix

 **Assertions:**
@@ -111,12 +138,12 @@ identifies engine-level root causes. Verdict is READY FOR RELEASE or NEEDS MORE

 **Expected behavior:**
 1. Skill detects no argument is provided
-2. Outputs usage guidance: e.g., "Usage: `/team-polish [feature or area]` — specify the feature or area to polish (e.g., `combat`, `main menu`, `inventory system`, `level-1`)"
+2. Outputs usage guidance: e.g., "Usage: `/team-polish [feature or area to polish] [--review full|lean|solo]` — specify the feature or area to polish (e.g., `combat`, `main menu`, `inventory system`, `level-1`)"
 3. Skill exits without spawning any agents

 **Assertions:**
 - [ ] Skill does NOT spawn any agents when no argument is provided
- [ ] Usage message includes the correct invocation format with argument examples
+- [ ] Usage message shows the full argument-hint — `/team-polish [feature or area to polish] [--review full|lean|solo]` — and argument examples
 - [ ] Skill does NOT attempt to guess a feature from project files
 - [ ] No `AskUserQuestion` is used — output is direct guidance

@@ -125,6 +152,7 @@ identifies engine-level root causes. Verdict is READY FOR RELEASE or NEEDS MORE
 ### Case 4: Engine-Level Bottleneck — engine-programmer spawned conditionally in Phase 2

 **Fixture:**
+- Resolved config block: `team.size: small`, `automation: collaborative`
 - Feature being polished: `open-world` environment streaming
 - Phase 1 identifies a performance bottleneck with a root cause in the rendering pipeline: "draw call overhead is caused by the engine's scene tree traversal in the spatial indexer — this is an engine-level issue, not a game code issue"
 - Performance budgets are defined; the rendering overhead exceeds target frame budget
@@ -135,16 +163,17 @@ identifies engine-level root causes. Verdict is READY FOR RELEASE or NEEDS MORE
 1. Phase 1: performance-analyst profiles the environment; identifies frame budget violation; root cause analysis points to engine-level rendering pipeline (spatial indexer traversal overhead)
 2. Phase 1 output explicitly classifies the root cause as engine-level
 3. `AskUserQuestion` presents the performance report including the engine-level root cause; user approves before Phase 2
-4. Phase 2: performance-analyst is spawned for game-code-level optimizations AND engine-programmer is spawned in parallel for the engine-level rendering fix
-5. Phases 3 and 4 also run in parallel with Phase 2 (visual and audio polish)
-6. engine-programmer addresses the spatial indexer traversal; provides profiler validation showing the fix reduces overhead
-7. Phase 5: qa-tester runs regression tests including tests for the engine-level fix
+4. Phase 2: engine-programmer (in the `small` set) is spawned for the engine-level rendering item on the optimisation list, writing `production/polish/open-world-engine-fixes-[date].md`; performance-analyst writes no code
+5. Phases 3 and 4 also run in parallel with Phase 2 (visual and audio polish); engine-programmer lists the engine files it will change along with the other agents' files, and one ask covers the set
+6. engine-programmer addresses the spatial indexer traversal after the yes; provides profiler validation showing the fix reduces overhead
+7. Phase 5: qa-tester runs regression tests including tests for the engine-level change
 8. Phase 6: orchestrator collects all results; if metrics are now within budget, verdict is READY FOR RELEASE; if not, NEEDS MORE WORK

 **Assertions:**
 - [ ] engine-programmer is NOT spawned in Phase 2 unless Phase 1 explicitly identifies an engine-level root cause
 - [ ] engine-programmer is spawned in Phase 2 when Phase 1 identifies an engine-level root cause
- [ ] engine-programmer and performance-analyst Task calls in Phase 2 are issued simultaneously (not sequentially)
+- [ ] engine-programmer's Phase 2 Agent call is issued alongside the Phase 3 and 4 calls (not sequentially), and performance-analyst is not re-spawned to change code
+- [ ] engine-programmer edits nothing before the one ask for the Phase 2–4 implementation set is answered yes
 - [ ] Phases 3 and 4 also run in parallel with Phase 2 (not deferred until Phase 2 completes)
 - [ ] engine-programmer's output includes profiler validation of the fix
 - [ ] qa-tester in Phase 5 runs regression tests that cover the engine-level change
@@ -155,6 +184,7 @@ identifies engine-level root causes. Verdict is READY FOR RELEASE or NEEDS MORE
 ### Case 5: Regression Found — Polish change broke an existing feature

 **Fixture:**
+- Resolved config block: `team.size: small`, `automation: collaborative`
 - Feature being polished: `inventory-ui`
 - Phases 1–4 complete successfully; performance and polish changes are applied
 - Phase 5: qa-tester runs regression tests and finds that a shader optimization applied in Phase 3 broke the item highlight glow effect on hover — an existing feature that was working before the polish pass
@@ -164,55 +194,111 @@ identifies engine-level root causes. Verdict is READY FOR RELEASE or NEEDS MORE
 **Expected behavior:**
 1. Phases 1–4 complete; polish changes include a shader optimization from technical-artist
 2. Phase 5: qa-tester runs regression tests and detects "Item highlight glow on hover no longer renders — regression introduced by shader optimization in Phase 3"
-3. qa-tester returns test results with the regression noted
-4. Orchestrator surfaces the regression immediately: "qa-tester: REGRESSION FOUND — `item-highlight-hover` glow broken by Phase 3 shader optimization"
-5. Subagent files a bug report asking "May I write the bug report to `production/qa/evidence/bug-polish-inventory-ui-[date].md`?" before writing
-6. Bug report is written after approval; it includes: the broken behavior, the polish change that caused it, reproduction steps, and severity
-7. `AskUserQuestion` presents the regression with options:
-   - Revert the shader optimization and find an alternative approach
-   - Fix the shader optimization to preserve the glow effect
-   - Accept the regression and schedule a fix in the next sprint
-8. Verdict: NEEDS MORE WORK (regression present regardless of user's chosen resolution path, unless fix is applied within the current session)
+3. qa-tester writes its findings to `production/polish/inventory-ui-verification-[date].md` (no per-write prompt) and returns the regression as a CONCERNS/BLOCKED line in its return contract
+4. The orchestrator confirms the verification file exists, then at the Phase 5 → Phase 6 transition writes qa-tester's full analysis in conversation — naming the broken behavior and the Phase 3 shader change that caused it — and captures the decision via `AskUserQuestion` with qa-tester's proposals as options
+5. Phase 6: the regression is listed among remaining issues with severity and a recommendation
+6. Verdict: NEEDS MORE WORK
+7. Next Steps: schedule the fix in `/sprint-plan update` and re-run `/team-polish` after fixes

 **Assertions:**
 - [ ] Regression is surfaced before Phase 6 sign-off
 - [ ] The specific broken behavior and the responsible change are both named in the report
- [ ] Subagent asks "May I write the bug report to [path]?" before filing
- [ ] Bug report includes: broken behavior, causal change, reproduction steps, severity
- [ ] `AskUserQuestion` offers options including revert, fix in place, and schedule later
+- [ ] qa-tester's findings are written to `production/polish/inventory-ui-verification-[date].md` without a separate approval prompt
+- [ ] `AskUserQuestion` at the Phase 5 → 6 transition presents the regression and qa-tester's proposed resolutions as selectable options
+- [ ] Phase 6 lists the regression as a remaining issue with severity
 - [ ] Verdict is NEEDS MORE WORK when a regression is present and unresolved
- [ ] Verdict may become READY FOR RELEASE only if the regression is fixed within the current polish session and qa-tester re-runs to confirm
+- [ ] Next Steps directs the fix to `/sprint-plan update` and a `/team-polish` re-run — no in-session fix is reported as verified
+
+---
+
+### Case 6: No Budgets Committed — NOT ASSESSED, not READY FOR RELEASE
+
+**Fixture:**
+- Resolved config block: `team.size: small`, `automation: collaborative`
+- `project.yaml` sets none of `performance.target_framerate`, `performance.frame_budget_ms`, `performance.draw_call_limit` or `performance.memory_ceiling_mb`, and no design doc states a budget for the area
+- Feature being polished: `main-menu`; every phase completes, and qa-tester finds no regressions
+
+**Input:** `/team-polish main-menu`
+
+**Expected behavior:**
+1. Phase 1: performance-analyst profiles the menu via `/perf-profile`; each metric is reported as measured but `NOT ASSESSED` — no committed budget — never as within budget or with headroom against a placeholder such as 16.67 ms
+2. Phases 2–5 run normally; nothing is found over budget and there are no regressions
+3. Phase 6: no known problem, but the budget comparison could not run, so the verdict is NOT ASSESSED — not READY FOR RELEASE — and the report names each unset `performance.*` key
+4. Next Steps: commit the budgets in `project.yaml` and re-run `/team-polish`; `/release-checklist` is not offered as the next step
+
+**Assertions:**
+- [ ] Verdict is NOT ASSESSED, not READY FOR RELEASE
+- [ ] The report names each unset `performance.*` key as the reason
+- [ ] No metric is described as within budget, and no headroom is computed against a placeholder budget
+- [ ] Next Steps asks for the budgets and a re-run rather than handing off to `/release-checklist`
+- [ ] A regression found in the same run would make the verdict NEEDS MORE WORK instead — the missing budgets do not mask a known problem
+
+---
+
+### Case 7: Default `individual` — the optimisation list is handed to `/dev-story`
+
+**Fixture:**
+- Resolved config block: `team.size: individual`, `automation: collaborative`
+- Budgets committed in `project.yaml` (as in Case 1)
+- Feature being polished: `crafting-menu`; Phase 1 finds a draw-call overrun owned by technical-artist and a script hot path in the crafting logic owned by gameplay-programmer — no engine-level root cause
+
+**Input:** `/team-polish crafting-menu`
+
+**Expected behavior:**
+1. The active-set line names performance-analyst + technical-artist; the not-spawned line names sound-designer, qa-tester, engine-programmer and tools-programmer
+2. Phase 1: performance-analyst writes `production/polish/crafting-menu-report-[date].md` with the optimisation list, each item naming its owner
+3. Phase 2: no programmer is active, so no agent implements the script item — performance-analyst does not implement it either; the draw-call item joins technical-artist's Phase 3 brief
+4. The report lists the gameplay-programmer item under "Optimisation list handed to `/dev-story`: `production/polish/crafting-menu-report-[date].md`"
+5. Phase 6: audio polish and hardening did not run; if the script hot path keeps a metric over budget the verdict is NEEDS MORE WORK, otherwise NOT ASSESSED
+6. Next Steps: implement the handed-off items with `/dev-story`, then re-run `/team-polish`
+
+**Assertions:**
+- [ ] No agent changes code for the gameplay-programmer item in this run, and performance-analyst changes nothing
+- [ ] The report names the optimisation list as handed to `/dev-story`, with the path and each item's owner
+- [ ] Verdict is never READY FOR RELEASE at `individual`
+- [ ] An over-budget metric the handed-off item targets makes the verdict NEEDS MORE WORK

 ---

 ## Protocol Compliance

+- [ ] At the default `team.size: individual`, the run opens with an `Active set (team.size: individual): performance-analyst + technical-artist` line and a `Not spawned this run:` line naming sound-designer, qa-tester, engine-programmer and tools-programmer — before any agent is spawned
 - [ ] Phase 1 (assessment) must complete before any other phase begins
- [ ] `AskUserQuestion` is used after every phase output before the next phase launches
- [ ] Phases 3 and 4 are always launched in parallel with Phase 2 (not deferred)
- [ ] engine-programmer is only spawned when Phase 1 explicitly identifies engine-level root causes
+- [ ] In `collaborative` mode, `AskUserQuestion` is used after every phase output before the next phase launches
+- [ ] Phases 3 and 4 are launched in parallel with Phase 2 whenever their agents are in the active set (not deferred)
+- [ ] engine-programmer is only spawned when Phase 1 explicitly identifies engine-level root causes, and only at `small` or `studio`
+- [ ] performance-analyst produces the optimisation list and never implements it; an item whose owner is not active is named as handed to `/dev-story`
+- [ ] Phase 2–4 implementation files are asked for once, as a set — not once per phase
 - [ ] No files are written by the orchestrator directly — all writes are delegated to sub-agents
- [ ] Each sub-agent enforces the "May I write to [path]?" protocol before any write
+- [ ] Sub-agents skip the per-write prompt only for their named `production/polish/` paths; any other write requires a "May I write" ask
+- [ ] A phase whose named artifact is missing on disk is treated as failed, not done
 - [ ] BLOCKED status from any agent is surfaced immediately — not silently skipped
 - [ ] A partial report is always produced when some agents complete and others block
- [ ] Verdict is exactly READY FOR RELEASE or NEEDS MORE WORK — no other verdict values used
- [ ] NEEDS MORE WORK verdict always lists specific remaining issues with severity
- [ ] Next Steps handoff references `/release-checklist` (on success) and `/sprint-plan update` + `/gate-check` (on failure)
+- [ ] Verdict is exactly one of READY FOR RELEASE, NOT ASSESSED or NEEDS MORE WORK — a known problem is NEEDS MORE WORK even when something else went unchecked, and READY FOR RELEASE is reachable only when every measured metric had a committed budget and every phase ran
+- [ ] At `team.size: individual`, sound-designer's audio polish and qa-tester's hardening are named as not run, so the verdict is NOT ASSESSED unless a known problem makes it NEEDS MORE WORK
+- [ ] NEEDS MORE WORK verdict always lists specific remaining issues with severity, the measured gap where there is one, and a recommendation
+- [ ] Next Steps handoff references `/release-checklist` (on success), `/sprint-plan update` and a `/team-polish` re-run (on failure), `/gate-check` before handing off to release, and, on NOT ASSESSED, supplying the missing budgets or phases before a re-run
+- [ ] At `team.size: studio`, Phase 5's qa-tester is told to find how the polished feature breaks rather than confirm it holds, and the report says the adversarial pass ran; no engine specialist is added

 ---

 ## Coverage Notes

- The tools-programmer optional agent (for content pipeline tool verification) is not
+- The tools-programmer optional agent (for content pipeline tool fixes) is not
  separately tested — it follows the same conditional spawn pattern as engine-programmer
-  and is invoked only when content authoring tools are involved in the polished area.
+  and is invoked in Phase 2, at `small` or `studio`, only when Phase 1 traces a cause
+  to a content authoring tool.
 - The "Retry with narrower scope" and "Skip this agent" resolution paths from the Error
  Recovery Protocol are not separately tested — they follow the same `AskUserQuestion`
  + partial-report pattern validated in Cases 2 and 5.
 - Phase 6 sign-off logic (collecting and comparing all metrics) is validated implicitly
  by Cases 1 and 2. The distinction between READY FOR RELEASE and NEEDS MORE WORK is
-  exercised in both directions across these cases.
+  exercised in both directions across these cases, and NOT ASSESSED by Case 6.
+- The `individual` path — audio polish and hardening not run, the optimisation list
+  handed to `/dev-story` — is given Case 7.
 - Soak testing and stress testing (Phase 5) are validated implicitly by Case 1's
  qa-tester output. Case 5 focuses on the regression detection aspect of Phase 5.
 - The "minimum spec hardware" test path in Phase 5 is not separately tested — it follows
  the same qa-tester delegation pattern when the hardware is available.
+- The `studio` addition (the adversarial review pass) is asserted in Protocol Compliance
+  but not given its own case.
@@ -2,29 +2,47 @@

 ## Skill Summary

-Orchestrates the QA team through a 7-phase structured testing cycle. Coordinates
-qa-lead (strategy, test plan, sign-off report) and qa-tester (test case writing,
-bug report writing). Covers scope detection, story classification, QA plan
-generation, smoke check gate, test case writing, manual QA execution with bug
-filing, and a final sign-off report with an APPROVED / APPROVED WITH CONDITIONS /
-NOT APPROVED verdict. Parallel qa-tester spawning is used in Phase 5 for
-independent stories.
+Orchestrates the QA team through a 6-phase structured testing cycle. Coordinates
+qa-lead (strategy, smoke check assessment, sign-off report) and qa-tester (test case
+writing, bug report writing). Phase 1 loads scope (sprint file, `feature:` form, or
+inferred from session state) and the project stage; Phase 2 classifies stories and
+takes the smoke check verdict from the latest `production/qa/smoke-*.md` report
+(UNKNOWN when none exists; NOT ASSESSED when the report says so — both continue
+with a warning and rule out APPROVED; FAIL stops the cycle); at `qa.level:
+minimal`, where tests are waived, a Logic, Integration or Config/Data story
+without a test is WAIVED and its evidence is the acceptance-criteria walk in
+manual QA; Phase 3 writes the QA plan after
+asking; Phase 4 spawns qa-tester with a named output path per manual-QA story —
+one spawn per story in parallel at `team.size: studio`, one for the whole group
+below it; Phase 5 walks manual QA, files bugs, has the tester retain screenshots
+and writes evidence artifacts after asking; Phase 6 produces a sign-off report,
+with a row for every story in scope, and a NOT ASSESSED / APPROVED / APPROVED WITH
+CONDITIONS / NOT APPROVED verdict. Phase 0 resolves `team.size` and the skill announces the
+active set before Phase 1. The orchestrator-level verdict is COMPLETE or BLOCKED.

 ---

 ## Static Assertions (Structural)

 - [ ] Has required frontmatter fields: `name`, `description`, `argument-hint`, `user-invocable`, `allowed-tools`
- [ ] Has ≥2 phase headings
+- [ ] Has ≥2 phase headings (Phase 1 through Phase 6)
 - [ ] Contains verdict keywords: COMPLETE, BLOCKED
- [ ] Contains verdict keywords for sign-off report: APPROVED, APPROVED WITH CONDITIONS, NOT APPROVED
- [ ] Contains "May I write" language for both the QA plan and the sign-off report
+- [ ] Contains sign-off verdict keywords: NOT ASSESSED, APPROVED, APPROVED WITH CONDITIONS, NOT APPROVED
+- [ ] Contains "May I write" language for every orchestrator write: the QA plan (Phase 3), the evidence artifacts (Phase 5) and the sign-off report (Phase 6)
 - [ ] Has an Error Recovery Protocol section
 - [ ] Uses `AskUserQuestion` at phase transitions to capture user approval before proceeding
- [ ] Phase 4 (smoke check) is a hard gate: FAIL stops the cycle
- [ ] Bug reports are written to `production/qa/bugs/` with `BUG-[NNN]-[short-slug].md` naming
- [ ] Next-step guidance differs by verdict (APPROVED / APPROVED WITH CONDITIONS / NOT APPROVED)
- [ ] Independent qa-tester tasks in Phase 5 are spawned in parallel
+- [ ] Phase 2 takes the smoke verdict from the most recent `production/qa/smoke-*.md` report, and a FAIL stops the cycle before Phase 3
+- [ ] Phase 4 names each qa-tester's output path: `production/qa/test-cases/[story-slug]-cases.md`
+- [ ] Bug reports are written to `production/qa/bugs/` with `BUG-[NNNN].md` naming — `/bug-report`'s numbering, so `/bug-report verify` finds them
+- [ ] Visual/Feel and UI stories that pass get a retained screenshot of each screen or effect touched under `production/qa/evidence/[story-slug]/`, confirmed on disk, and an evidence artifact at `production/qa/evidence/[story-slug]-evidence.md` that references it — the screenshot closes a UI story; a Visual/Feel story also needs the lead sign-off
+- [ ] Next-step guidance differs by verdict (NOT ASSESSED / APPROVED / APPROVED WITH CONDITIONS / NOT APPROVED)
+- [ ] Phase 0 resolves `team.size`, and the skill requires a one-line active-set announcement before Phase 1
+- [ ] Phase 0 resolves `qa.level`; at `minimal` a Logic, Integration or Config/Data story without a test gets its acceptance criteria walked in Phase 4–5 — tests WAIVED, never counted as missing evidence
+- [ ] The Phase 2 smoke verdict list includes NOT ASSESSED, which continues with a warning like UNKNOWN and makes the sign-off NOT ASSESSED
+- [ ] Phase 1 reads the Open bugs in scope from `production/qa/bugs/` (open unless `Closed` or `Verified Fixed`) and passes them into the Phase 2 and Phase 6 briefs
+- [ ] The Phase 6 brief carries the evidence and the verdict rules and names no verdict; the orchestrator checks the qa-lead's verdict against the rules before writing
+- [ ] Phase 4 spawns one qa-tester per story, in parallel, at `team.size: studio`; at `small` and `individual` one qa-tester spawn covers the whole group
+- [ ] The Phase 6 sign-off gives every story in scope a Test Coverage Summary row — BLOCKED and unexecuted stories included — and its template shows a BLOCKED row

 ---

@@ -33,30 +51,33 @@ independent stories.
 ### Case 1: Happy Path — All stories pass manual QA, APPROVED verdict

 **Fixture:**
- `production/sprints/sprint-03/` exists with 4 story files
- Stories are a mix of types: 1 Logic, 1 Integration, 2 Visual/Feel
+- Resolved config block: `team.size: small`, `automation: collaborative`
+- `production/sprints/sprint-03.md` lists 4 stories whose story files exist
+- Stories are a mix of types: 1 Logic (its unit test exists and passes), 1 Integration (no automated test), 2 Visual/Feel
 - All stories have acceptance criteria populated
- `tests/smoke/` contains a smoke test list; all items are verifiable
- No existing bugs in `production/qa/bugs/`
+- The most recent `production/qa/smoke-[date].md` report has verdict PASS
+- `production/qa/bugs/` contains no bugs

 **Input:** `/team-qa sprint-03`

 **Expected behavior:**
-1. Phase 1: Reads all story files in `production/sprints/sprint-03/`; reads `production/stage.txt`; reports "Found 4 stories. Current stage: [stage]. Ready to begin QA strategy?"
-2. Phase 2: Spawns `qa-lead` via Task; produces strategy table classifying all 4 stories; no blockers flagged; presents to user; AskUserQuestion: user selects "Looks good — proceed to test plan"
-3. Phase 3: Produces QA plan document; asks "May I write the QA plan to `production/qa/qa-plan-sprint-03-[date].md`?"; writes after approval
-4. Phase 4: Spawns `qa-lead` via Task; reviews `tests/smoke/`; returns PASS; reports "Smoke check passed. Proceeding to test case writing."
-5. Phase 5: Spawns `qa-tester` via Task for each Visual/Feel and Integration story (2–3 stories); run in parallel; presents test cases grouped by story; AskUserQuestion per group; user approves
-6. Phase 6: Walks through each approved story; user marks all as PASS; result summary: "Stories PASS: 4, FAIL: 0, BLOCKED: 0"
-7. Phase 7: Spawns `qa-lead` via Task to produce sign-off report; report shows all stories PASS; no bugs filed; Verdict: APPROVED; asks "May I write this QA sign-off report to `production/qa/qa-signoff-sprint-03-[date].md`?"; writes after approval
+1. Before any spawn, one line announces the active set for `team.size: small`
+2. Phase 1: Globs `production/sprints/sprint-*.md`, matches sprint number 3 (`sprint-03.md`) and reads it; reads `project.stage` from `project.yaml` (fallback `production/stage.txt`); reads the open bugs in scope (none on file); reports "QA cycle starting for sprint-03. Found 4 stories. Open bugs in scope: none on file. Current stage: [stage]. Ready to begin QA strategy?"
+3. Phase 2: Spawns `qa-lead` via Agent; classifies all 4 stories in the strategy table; reads the smoke report and records `Smoke Check: PASS — source: production/qa/smoke-[date].md` without re-interviewing the user; presents the strategy; `AskUserQuestion` "QA Strategy Review": user selects "Looks good — proceed to test plan"
+4. Phase 3: Produces QA plan (scope, classification table, automated/manual scope, entry and exit criteria); asks "May I write the QA plan to `production/qa/qa-plan-sprint-03-[date].md`?"; writes after approval
+5. Phase 4: Spawns one `qa-tester` via Agent for the Integration and both Visual/Feel stories (per-story parallel spawns are the `studio` shape), its prompt naming `production/qa/test-cases/[story-slug]-cases.md` for each story; test cases presented grouped by story; `AskUserQuestion` per group; user approves
+6. Phase 5: `AskUserQuestion` per story (PASS / PASS WITH NOTES / FAIL / BLOCKED); user marks all as PASS; for each Visual/Feel story the tester saves a screenshot under `production/qa/evidence/[story-slug]/` and the orchestrator confirms it is on disk; after "May I write the evidence for [story titles] to `production/qa/evidence/`?" it writes `production/qa/evidence/[story-slug]-evidence.md`, referencing the screenshots, with sign-off rows left unchecked unless signed off in this session; result summary: "Stories PASS: 4, PASS WITH NOTES: 0, FAIL: 0, BLOCKED: 0"
+7. Phase 6: Spawns `qa-lead` via Agent to produce sign-off report; every story has executed evidence; no bugs filed; Verdict: APPROVED; asks "May I write this QA sign-off report to `production/qa/qa-signoff-sprint-03-[date].md`?"; writes after approval
 8. Verdict: COMPLETE — QA cycle finished

 **Assertions:**
+- [ ] Active-set line naming `team.size: small` appears before the first agent is spawned
 - [ ] Phase 1 correctly counts and reports 4 stories with current stage
 - [ ] Strategy table in Phase 2 classifies all 4 stories with correct types
+- [ ] Smoke check verdict is taken from the existing `production/qa/smoke-*.md` report and its source is shown
 - [ ] QA plan written only after "May I write?" approval
- [ ] Smoke check PASS allows pipeline to continue without user intervention
- [ ] Phase 5 qa-tester tasks for independent stories are issued in parallel
+- [ ] Phase 4 spawns a single qa-tester at `team.size: small`, and its prompt names each story's `production/qa/test-cases/` path
+- [ ] Each passing Visual/Feel story has a retained screenshot on disk under `production/qa/evidence/[story-slug]/`, and its evidence artifact references it and is written only after the "May I write" ask
 - [ ] Sign-off report includes Test Coverage Summary table and Verdict: APPROVED
 - [ ] Sign-off report written only after "May I write?" approval
 - [ ] Verdict: COMPLETE appears in final output
@@ -64,59 +85,62 @@ independent stories.

 ---

-### Case 2: Smoke Check Fail — QA cycle stops at Phase 4
+### Case 2: Smoke Check Fail — QA cycle stops at Phase 2

 **Fixture:**
- `production/sprints/sprint-04/` exists with 3 story files
- `tests/smoke/` exists with 5 smoke test items; 2 items cannot be verified (e.g., build is unstable, core navigation broken)
+- Resolved config block: `team.size: small`, `automation: collaborative`
+- `production/sprints/sprint-04.md` lists 3 stories
+- The most recent `production/qa/smoke-[date].md` report has verdict FAIL with 2 listed failures (build unstable on launch, core navigation broken)

 **Input:** `/team-qa sprint-04`

 **Expected behavior:**
-1. Phases 1–3 complete normally; QA plan is written
-2. Phase 4: Spawns `qa-lead` via Task; smoke check returns FAIL; two specific failures are identified
-3. Skill reports: "Smoke check failed. QA cannot begin until these issues are resolved: [list of 2 failures]. Fix them and re-run `/smoke-check`, or re-run `/team-qa` once resolved."
-4. Skill stops immediately after Phase 4 — no Phase 5, 6, or 7 is executed
-5. No sign-off report is produced; no "May I write?" for a sign-off is issued
+1. Phase 1 completes normally
+2. Phase 2: Spawns `qa-lead` via Agent; qa-lead reads the smoke report and records `Smoke Check: FAIL` with both failures listed prominently
+3. `AskUserQuestion` "QA Strategy Review" is presented, including the option "Smoke check failed — fix issues and re-run /team-qa"
+4. Skill does not proceed to Phase 3: it surfaces the failures from the smoke report and stops — the user must fix them, re-run `/smoke-check sprint`, and then re-run `/team-qa`
+5. No QA plan, test cases, manual QA or sign-off report is produced; a partial report is given
+6. Verdict: BLOCKED — smoke check failed

 **Assertions:**
- [ ] Smoke check FAIL causes the pipeline to halt at Phase 4 — Phases 5, 6, 7 are NOT executed
+- [ ] Smoke check verdict comes from the `production/qa/smoke-*.md` report — qa-lead does not re-derive it or re-interview the user
+- [ ] Smoke check FAIL halts the pipeline at Phase 2 — Phases 3, 4, 5, 6 are NOT executed
 - [ ] Failure list is shown to the user explicitly (not summarized vaguely)
- [ ] Skill recommends `/smoke-check` and `/team-qa` re-run as remediation steps
- [ ] No QA sign-off report is written or offered
- [ ] Skill does NOT produce a COMPLETE verdict
- [ ] Any QA plan already written in Phase 3 is preserved (not deleted)
+- [ ] Skill recommends `/smoke-check sprint` and a `/team-qa` re-run as remediation steps
+- [ ] No QA plan and no QA sign-off report is written or offered
+- [ ] Orchestrator verdict is BLOCKED, not COMPLETE

 ---

 ### Case 3: Bug Found — Visual/Feel story fails manual QA, bug report filed

 **Fixture:**
- `production/sprints/sprint-05/` exists with 2 story files: 1 Logic (passes automated tests), 1 Visual/Feel
- `tests/smoke/` smoke check passes
+- Resolved config block: `team.size: small`, `automation: collaborative`
+- `production/sprints/sprint-05.md` lists 2 stories: 1 Logic (its automated test passes), 1 Visual/Feel
+- The most recent `production/qa/smoke-[date].md` report has verdict PASS
 - The Visual/Feel story's animation timing is visibly wrong (acceptance criterion not met)
- `production/qa/bugs/` directory exists (empty or with existing bugs)
+- `production/qa/bugs/` already contains `BUG-0001.md` and `BUG-0002.md`

 **Input:** `/team-qa sprint-05`

 **Expected behavior:**
-1. Phases 1–5 complete normally; test cases are written for the Visual/Feel story
-2. Phase 6: User marks Visual/Feel story as FAIL; AskUserQuestion collects failure description: "Animation plays at 2x speed — jitter visible on every loop"
-3. Phase 6: Spawns `qa-tester` via Task to write a formal bug report; bug report written to `production/qa/bugs/BUG-001-animation-speed-jitter.md` (or next increment if bugs exist); report includes severity field
-4. Result summary: "Stories PASS: 1, FAIL: 1 — bugs filed: BUG-001"
-5. Phase 7: Spawns `qa-lead` to produce sign-off report; Bugs Found table lists BUG-001 with severity and status Open; Verdict: NOT APPROVED (S1/S2 bug open, or FAIL without documented workaround)
+1. Phases 1–4 complete normally; test cases are written for the Visual/Feel story
+2. Phase 5: User marks Visual/Feel story as FAIL; `AskUserQuestion` collects failure description: "Animation plays at 2x speed — jitter visible on every loop"
+3. Phase 5: Spawns `qa-tester` via Agent to write a formal bug report at `production/qa/bugs/BUG-0003.md`; report includes severity field
+4. Result summary: "Stories PASS: 1, PASS WITH NOTES: 0, FAIL: 1 — bugs filed: BUG-0003, BLOCKED: 0"
+5. Phase 6: Spawns `qa-lead` to produce sign-off report; every story has executed evidence; Bugs Found table lists BUG-0003 with story, severity and status Open; Verdict: NOT APPROVED (a story FAILed without documented workaround)
 6. Sign-off report write is offered; writes after approval
 7. Next step: "Resolve S1/S2 bugs and re-run `/team-qa` or targeted manual QA before advancing."

 **Assertions:**
- [ ] FAIL result in Phase 6 triggers AskUserQuestion to collect the failure description before the bug report is written
- [ ] `qa-tester` is spawned via Task to write the bug report — orchestrator does not write it directly
- [ ] Bug report follows naming convention: `BUG-[NNN]-[short-slug].md` in `production/qa/bugs/`
- [ ] Bug report NNN is incremented correctly from existing bugs in the directory
- [ ] Phase 7 sign-off report Bugs Found table includes the bug ID, story name, severity, and status
+- [ ] FAIL result in Phase 5 triggers `AskUserQuestion` to collect the failure description before the bug report is written
+- [ ] `qa-tester` is spawned via Agent to write the bug report — orchestrator does not write it directly
+- [ ] Bug report follows `/bug-report`'s naming: `BUG-[NNNN].md` in `production/qa/bugs/`
+- [ ] The ID is one past the highest existing bug, zero-padded to four digits (BUG-0003)
+- [ ] Phase 6 sign-off report Bugs Found table includes the bug ID, story name, severity, and status
 - [ ] Verdict in sign-off report is NOT APPROVED
 - [ ] Next step explicitly mentions re-running `/team-qa`
- [ ] Verdict: COMPLETE is still issued by the orchestrator (the QA cycle finished — the verdict is NOT APPROVED, but the skill completed its pipeline)
+- [ ] Verdict: COMPLETE is still issued by the orchestrator (the QA cycle finished — the sign-off verdict is NOT APPROVED, but the skill completed its pipeline)

 ---

@@ -125,27 +149,29 @@ independent stories.
 **Fixture (variant A — state files present):**
 - `production/session-state/active.md` exists and contains a reference to `sprint-06`
 - `production/sprint-status.yaml` exists and identifies `sprint-06` as active
+- `production/sprints/sprint-06.md` exists

-**Fixture (variant B — state files absent):**
+**Fixture (variant B — no sprint, as at `rigor: minimal`):**
 - `production/session-state/active.md` does NOT exist
 - `production/sprint-status.yaml` does NOT exist
+- No sprint files exist; epics exist under `production/epics/`

 **Input:** `/team-qa` (no argument)

 **Expected behavior (variant A):**
-1. Phase 1: No argument provided; reads `production/session-state/active.md`; reads `production/sprint-status.yaml`
-2. Detects `sprint-06` as the active sprint from both sources
-3. Proceeds as if `/team-qa sprint-06` was the input; reports "No sprint argument provided — inferred sprint-06 from session state. Found [N] stories."
+1. Phase 1: No argument provided; reads `production/session-state/active.md` and `production/sprint-status.yaml`
+2. Detects `sprint-06` as the active sprint
+3. Proceeds as if `/team-qa sprint-06` was the input; the Phase 1 report line names it: "QA cycle starting for sprint-06. Found [N] stories. Open bugs in scope: [N or none on file]. Current stage: [stage]. Ready to begin QA strategy?"

 **Expected behavior (variant B):**
-1. Phase 1: No argument provided; attempts to read `production/session-state/active.md` — file missing; attempts to read `production/sprint-status.yaml` — file missing
-2. Cannot infer sprint; uses AskUserQuestion: "Which sprint or feature should QA cover?" with options to type a sprint identifier or cancel
+1. Phase 1: No argument provided; attempts to read both state files — both missing; no sprint exists
+2. Asks the user which epic to cover, then scopes the run as `feature: [epic-slug]` — it does not invent a sprint

 **Assertions:**
 - [ ] Skill does NOT default to a hardcoded sprint name when no argument is provided
 - [ ] Skill reads both `production/session-state/active.md` AND `production/sprint-status.yaml` before asking the user (variant A)
- [ ] When both state files are absent, skill uses AskUserQuestion rather than guessing (variant B)
- [ ] Inferred sprint is reported to the user before proceeding (variant A transparency)
+- [ ] When no sprint can be inferred, skill asks which epic to cover and uses the `feature: [epic-slug]` form rather than guessing (variant B)
+- [ ] The inferred sprint is named in the Phase 1 report line before Phase 2 begins (variant A)
 - [ ] Skill does NOT error out when state files are missing — it falls back to asking (variant B)

 ---
@@ -153,52 +179,142 @@ independent stories.
 ### Case 5: Mixed Results — Some PASS, one FAIL with S1 bug, one BLOCKED

 **Fixture:**
- `production/sprints/sprint-07/` exists with 4 story files
- Smoke check passes
+- Resolved config block: `team.size: small`, `automation: collaborative`
+- `production/sprints/sprint-07.md` lists 4 stories
+- The most recent `production/qa/smoke-[date].md` report has verdict PASS
 - Story A (Logic): automated test passes — PASS
 - Story B (UI): manual QA — PASS WITH NOTES (minor text overflow)
 - Story C (Visual/Feel): manual QA — FAIL; tester identifies S1 crash on ability activation
 - Story D (Integration): cannot test — BLOCKED (dependency system not yet implemented)
+- `production/qa/bugs/` is empty

 **Input:** `/team-qa sprint-07`

 **Expected behavior:**
-1. Phases 1–5 proceed; Phase 5 test cases cover stories B, C, D
-2. Phase 6: User marks Story A as implicitly PASS (automated); Story B: PASS WITH NOTES; Story C: FAIL; Story D: BLOCKED
-3. After Story C FAIL: qa-tester spawned to write bug report `BUG-001-crash-ability-activation.md` with S1 severity
-4. Result summary presented: "Stories PASS: 1, PASS WITH NOTES: 1, FAIL: 1 — bugs filed: BUG-001 (S1), BLOCKED: 1"
-5. Phase 7: qa-lead produces sign-off report covering all 4 stories; BUG-001 listed as S1/Open; Story D listed as BLOCKED; Verdict: NOT APPROVED
-6. Sign-off report written after "May I write?" approval
-7. Next step: "Resolve S1/S2 bugs and re-run `/team-qa` or targeted manual QA before advancing."
+1. Phases 1–4 proceed; Phase 4 test cases cover stories B, C, D
+2. Phase 5: Story A is PASS from its automated test; user marks Story B: PASS WITH NOTES; Story C: FAIL; Story D: BLOCKED
+3. Story B (UI) gets a retained screenshot of each screen it touched, saved by the tester under `production/qa/evidence/[story-slug]/` and confirmed on disk; its evidence artifact at `production/qa/evidence/[story-slug]-evidence.md` references them and is written only after the "May I write" ask
+4. After Story C FAIL: failure description collected; qa-tester spawned to write bug report `BUG-0001.md` with S1 severity
+5. Result summary presented: "Stories PASS: 1, PASS WITH NOTES: 1, FAIL: 1 — bugs filed: BUG-0001, BLOCKED: 1"
+6. Phase 6: qa-lead produces sign-off report covering all 4 stories; BUG-0001 listed as S1/Open; Story D listed as BLOCKED with no executed evidence; Verdict: NOT APPROVED — the open S1 is a known failure and is reported as such, not demoted to NOT ASSESSED by the unexecuted Story D
+7. Sign-off report written after "May I write?" approval
+8. Next step: "Resolve S1/S2 bugs and re-run `/team-qa` or targeted manual QA before advancing."

 **Assertions:**
- [ ] All 4 stories appear in the Phase 7 sign-off report Test Coverage Summary table — none are silently omitted
- [ ] Story D (BLOCKED) is listed in the report with a BLOCKED status, not silently dropped
- [ ] S1 bug causes Verdict: NOT APPROVED regardless of the other stories passing
+- [ ] All 4 stories appear in the Phase 6 sign-off report Test Coverage Summary table — none are silently omitted
+- [ ] Story D (BLOCKED) is listed in the report with a BLOCKED status and named as lacking executed evidence, not silently dropped
+- [ ] S1 bug causes Verdict: NOT APPROVED regardless of the other stories passing, and regardless of Story D being unexecuted
 - [ ] PASS WITH NOTES stories do not downgrade to FAIL — they are tracked separately
- [ ] BUG-001 severity is listed as S1 in the Bugs Found table
+- [ ] Story B's evidence is its retained screenshots — a UI story needs no lead sign-off to close
+- [ ] BUG-0001 severity is listed as S1 in the Bugs Found table
 - [ ] Partial results are preserved — the sign-off report is still produced even with failures and blocks
 - [ ] Verdict: COMPLETE is issued by the orchestrator (pipeline completed); sign-off verdict is NOT APPROVED

 ---

+### Case 6: `qa.level: minimal` — a Logic story with no test is evidenced by its acceptance-criteria walk
+
+**Fixture:**
+- Resolved config block: `team.size: small`, `automation: collaborative`, `qa.level: minimal (rigor:minimal)`
+- No sprint files and no `production/sprint-status.yaml`; `production/epics/combat/` holds 2 story files, both `In Review`: story-001 (Logic, no test file anywhere) and story-002 (UI)
+- The most recent `production/qa/smoke-[date].md` report has verdict PASS (its automated row WAIVED)
+- `production/qa/bugs/` contains no bugs
+
+**Input:** `/team-qa feature: combat`
+
+**Expected behavior:**
+1. Phase 2: qa-lead's strategy table marks story-001's Automated Required as `WAIVED` — tests are waived at `qa.level: minimal` — and puts it in manual QA; it is not flagged as missing test evidence or as a blocker
+2. Phase 3: the QA plan lists no automated test requirements; its entry criteria take the stories' status from the story files (feature scope), not from `production/sprint-status.yaml`
+3. Phase 4: test cases are written for both stories — story-001's walk its acceptance criteria
+4. Phase 5: the tester answers PASS for both; story-002's retained screenshot is saved and confirmed on disk
+5. Phase 6: the Test Coverage Summary shows story-001 as `WAIVED (qa.level: minimal)` under Auto Test with its criteria walked; every story has executed evidence, so the verdict is APPROVED
+
+**Assertions:**
+- [ ] story-001 is never reported as missing its test, and its acceptance-criteria walk is its executed evidence
+- [ ] The sign-off verdict is APPROVED, not NOT ASSESSED
+- [ ] The UI story still needs its retained screenshot — `qa.level: minimal` waives tests, not the look
+- [ ] Entry criteria at `feature:` scope read the story files' Status, not `production/sprint-status.yaml`
+- [ ] No next step tells the user to write Logic tests
+
+---
+
+### Case 7: Smoke report NOT ASSESSED — continue with a warning, sign-off NOT ASSESSED
+
+**Fixture:**
+- Resolved config block: `team.size: small`, `automation: collaborative`, `qa.level: standard`
+- `production/sprints/sprint-008.md` lists 2 stories: 1 Logic (its unit test exists and passes) and 1 Visual/Feel
+- The most recent `production/qa/smoke-[date].md` report has verdict NOT ASSESSED — Batch 3 was offered and skipped
+- `production/qa/bugs/` contains no bugs
+
+**Input:** `/team-qa sprint-8`
+
+**Expected behavior:**
+1. Phase 1 matches `sprint-008.md` by its number
+2. Phase 2: records `Smoke Check: NOT ASSESSED — Batch 3 skipped — source: production/qa/smoke-[date].md` and warns that the last smoke check could not assess it, recommending a `/smoke-check sprint` re-run; the cycle continues
+3. Phases 3–5 run; both stories PASS and the Visual/Feel story's evidence is retained
+4. Phase 6: every story has executed evidence, but the smoke check was NOT ASSESSED, so the sign-off verdict is **NOT ASSESSED** — never APPROVED
+
+**Assertions:**
+- [ ] The NOT ASSESSED smoke verdict is taken from the report and shown with its source — not read as PASS or UNKNOWN
+- [ ] The cycle does not stop at Phase 2 on NOT ASSESSED (only FAIL stops it)
+- [ ] The sign-off verdict is NOT ASSESSED even though every story passed
+- [ ] The next step names re-running `/smoke-check` before `/team-qa`
+
+---
+
+### Case 8: An open S1 already on file — known before sign-off, and the brief names no verdict
+
+**Fixture:**
+- Resolved config block: `team.size: small`, `automation: collaborative`, `qa.level: standard`
+- `production/sprints/sprint-009.md` lists 2 stories in the Combat system: 1 Logic (its unit test passes) and 1 UI
+- `production/qa/bugs/BUG-0004.md`: System Combat, `**Severity**: S1-Critical`, `**Status**: Open` — filed before this cycle; `BUG-0002.md` (Combat, S2) has `**Status**: Closed`
+- The most recent `production/qa/smoke-[date].md` report has verdict PASS
+
+**Input:** `/team-qa sprint-9`
+
+**Expected behavior:**
+1. Phase 1 greps the bug files and reports "Open bugs in scope: 1 — S1: 1"; the closed BUG-0002 is not counted
+2. Phase 2's brief to qa-lead carries BUG-0004, and the strategy lists it under **Open bugs in scope** as a known failure
+3. Phases 3–5 run; both stories PASS and the UI story's screenshots are retained
+4. Phase 6's brief passes the strategy, the smoke verdict, both stories' results, BUG-0004 and the verdict rules — it names no verdict, pre-fills no `### Verdict:` line and does not say which fact decides it
+5. The qa-lead returns NOT APPROVED (an open S1 bug in scope); the Bugs Found table lists BUG-0004; the orchestrator checks that verdict against the rules, then asks to write
+
+**Assertions:**
+- [ ] BUG-0004 is known from Phase 1 and appears in the Phase 2 strategy — not first discovered at sign-off, and never missed
+- [ ] The sign-off verdict is NOT APPROVED although every story passed — never NOT ASSESSED or APPROVED
+- [ ] The Phase 6 brief names no verdict and no deciding fact; the qa-lead reaches NOT APPROVED from the rules
+- [ ] A closed bug is not counted as open
+
+---
+
 ## Protocol Compliance

- [ ] `AskUserQuestion` used at Phase 2 (strategy review), Phase 5 (test case approval per group), and Phase 6 (per-story manual QA result)
- [ ] Phase 4 smoke check is a hard gate: FAIL halts the pipeline at Phase 4 with no exceptions
- [ ] "May I write?" asked separately for QA plan (Phase 3) and sign-off report (Phase 7)
- [ ] Bug reports are always written by `qa-tester` via Task — orchestrator does not write directly
- [ ] Phase 5 qa-tester tasks for independent stories are issued in parallel where possible
+- [ ] A manual-QA result is recorded only as the tester gave it — never filled in for them; an unanswered story stays unexecuted
+- [ ] In Phase 6 the qa-lead returns the sign-off text and writes no file; the orchestrator writes it after the ask
+- [ ] A bug filed in Phase 5 uses `/bug-report`'s Severity and Priority labels exactly
+- [ ] At the default `team.size: individual`, the run opens with an active-set line naming qa-tester as the always-active agent and stating that qa-lead is spawned only at phase gates (the decision points the pipeline lists, whatever the `automation` mode) — before any agent is spawned
+- [ ] `AskUserQuestion` used at Phase 2 (strategy review), Phase 4 (test case approval per group), and Phase 5 (per-story manual QA result and failure description)
+- [ ] Phase 2 smoke check is a hard gate: FAIL halts the pipeline before Phase 3
+- [ ] When no `production/qa/smoke-*.md` report exists, the smoke status is UNKNOWN, the warning "No smoke check report found. Recommend running `/smoke-check sprint` before QA. Proceeding with caution." is shown, and the cycle continues
+- [ ] A smoke report whose verdict is NOT ASSESSED is surfaced with what did not run, and the cycle continues as for UNKNOWN
+- [ ] With no smoke report (UNKNOWN), or one that is NOT ASSESSED, the sign-off verdict is NOT ASSESSED even when every story passes — never APPROVED or APPROVED WITH CONDITIONS — unless an open S1/S2 bug, or a FAIL without a documented workaround, makes it NOT APPROVED
+- [ ] "May I write?" is asked before every orchestrator write: the QA plan (Phase 3), each group's evidence artifacts (Phase 5) and the sign-off report (Phase 6)
+- [ ] Bug reports are always written by `qa-tester` via Agent — orchestrator does not write them directly
+- [ ] Every Phase 4 qa-tester prompt names each story's output path; per-story parallel spawns happen only at `team.size: studio`
+- [ ] Evidence artifacts never carry pre-ticked sign-off rows for a sign-off that did not happen in the session
 - [ ] Error recovery: any BLOCKED agent is surfaced immediately with AskUserQuestion options
 - [ ] Partial report always produced — no work is discarded because one story failed or blocked
- [ ] Sign-off verdict rules are strictly applied: any S1/S2 bug open = NOT APPROVED; no exceptions
- [ ] Orchestrator-level Verdict: COMPLETE is distinct from the sign-off report's APPROVED/NOT APPROVED verdict
+- [ ] Open bugs already on file are read in Phase 1 and reach both qa-lead briefs; no brief to qa-lead names the sign-off verdict
+- [ ] Sign-off verdict rules are strictly applied: any S1/S2 bug open = NOT APPROVED; APPROVED and APPROVED WITH CONDITIONS require executed evidence for every story in scope
+- [ ] Orchestrator-level Verdict: COMPLETE is distinct from the sign-off report's verdict

 ---

 ## Coverage Notes

- The "APPROVED WITH CONDITIONS" verdict path (S3/S4 bugs, PASS WITH NOTES) is covered implicitly by Case 5's PASS WITH NOTES story (Story B) — if no S1/S2 bugs existed, that case would produce APPROVED WITH CONDITIONS. A dedicated case is not required as the verdict logic is table-driven.
- The `feature: [system-name]` argument form is not separately tested — it follows the same Phase 1 logic as the sprint form, using glob instead of directory read. The no-argument inference path (Case 4) provides sufficient coverage of the detection logic.
+- The "APPROVED WITH CONDITIONS" verdict path (S3/S4 bugs, PASS WITH NOTES with every story executed) is not given a dedicated case; Case 5's Story B would produce it if no S1/S2 bug were open and Story D had been executed.
+- The NOT ASSESSED verdict with no known failure is covered for a NOT ASSESSED smoke report (Case 7); one story BLOCKED with the rest PASS, or no smoke report at all, is not given a dedicated case — the smoke-UNKNOWN rule is asserted in Protocol Compliance.
+- The `studio` shape (one qa-tester per story, in parallel) is asserted structurally but not given a case; Cases 1, 3 and 5 run at `small`.
+- The `feature: [system-name]` argument form is exercised by Case 6 — it follows the same Phase 1 logic as the sprint form, using glob instead of the sprint file. Case 4 variant B exercises the epic fallback.
 - Logic stories with passing automated tests do not need manual QA — this is validated implicitly by Case 5 (Story A) where the Logic story receives no manual QA phase.
- Parallel qa-tester spawning in Phase 5 is validated implicitly by Case 1 (multiple Visual/Feel stories issued simultaneously); no dedicated parallelism case is required beyond the Static Assertions check.
+- The session-state append to `production/session-state/active.md` after the final phase is not asserted.
@@ -4,11 +4,21 @@

 Orchestrates the release team through a 7-phase pipeline from release candidate to
 deployment and post-release monitoring. Coordinates release-manager, qa-lead,
-devops-engineer, producer, security-engineer (optional, required for online/
-multiplayer), network-programmer (optional, required for multiplayer),
-analytics-engineer, and community-manager. Phase 3 agents run in parallel. Ends
-with a go/no-go decision; deployment (Phase 6) is skipped if the producer calls
-NO-GO. Closes with a post-release monitoring plan.
+devops-engineer, producer, security-engineer (required for online/multiplayer/player
+data), network-programmer (required for multiplayer), analytics-engineer,
+localization-lead, performance-analyst and community-manager. Phase 0 resolves
+`review_mode`, `automation`, `team.size`, `workflow` and `project.stage`.
+`/gate-check release` is the readiness gate that must pass before a release, so
+when `project.stage` is not `Release` the skill stops before Phase 1, spawns
+nothing, says "run `/gate-check release` first", and offers an explicit override
+that is recorded (`Stage override: …`) in the go/no-go record and the report — it
+never sets `project.stage` itself. The skill announces the active set before
+Phase 1 — the default `individual` spawns release-manager alone. Each agent writes
+to its own named file under `production/releases/` (patch notes under
+`docs/patch-notes/`). Phase 3 agents run in parallel. Ends with a go/no-go
+decision; deployment (Phase 6) is skipped if the producer calls NO-GO and, on GO,
+still requires an explicit `AskUserQuestion` approval in every automation mode.
+Closes with a post-release monitoring plan.

 ---

@@ -17,14 +27,21 @@ NO-GO. Closes with a post-release monitoring plan.
 - [ ] Has required frontmatter fields: `name`, `description`, `argument-hint`, `user-invocable`, `allowed-tools`
 - [ ] Has ≥2 phase headings
 - [ ] Contains verdict keywords: COMPLETE, BLOCKED
- [ ] Contains "May I write" language in the File Write Protocol section (delegated to sub-agents)
- [ ] Has a File Write Protocol section stating that the orchestrator does not write files directly
- [ ] Has an Error Recovery Protocol section with four recovery options (surface / assess / offer options / partial report)
- [ ] Has a next-step handoff referencing post-release monitoring, `/retrospective`, and `production/stage.txt`
+- [ ] File Write Protocol distinguishes sub-agents (bounded exception: named path, new artifact under `production/`, `docs/` or `tests/`, gated phase — no per-write prompt) from sub-skills (normal protocol — they ask before writing), and requires explicit confirmation for tags, pushes, builds and storefront changes
+- [ ] File Write Protocol section states that the orchestrator does not write files directly
+- [ ] Names a destination per agent, so no two parallel agents share a file: `production/releases/release-plan-[version].md`, `release-checklist-[version].md`, `qa-gate-[version].md`, `build-[version].md`, `security-signoff-[version].md`, `netcode-signoff-[version].md`, `localization-signoff-[version].md`, `performance-signoff-[version].md`, `analytics-signoff-[version].md`, `go-no-go-[version].md`, `announcement-[version].md`, `release-report-[version].md`, and `docs/patch-notes/[version].md`
+- [ ] Error Recovery Protocol section is present: verify a named artifact is on disk, surface BLOCKED immediately, always produce a partial report, full procedure (surface / assess / offer options / partial report) in `.claude/docs/error-recovery-protocol.md`
+- [ ] Phase 0 resolves `project.stage`, and a stage check before Phase 1 stops when it is not `Release` ("run `/gate-check release` first"), spawning nothing; the only way past it is an explicit `AskUserQuestion` override, asked in every `automation` mode and recorded as a `Stage override:` line in the go/no-go record and the final report
+- [ ] Has a next-step handoff referencing post-release monitoring and `/retrospective`; the skill does not write `project.stage` or `production/stage.txt` itself
+- [ ] qa-lead checks open bugs at the release gate's thresholds for the resolved `workflow`: S1 at every tier, S2 and S3 too at `full`
+- [ ] A "phase gate" is a decision point the pipeline itself lists, whatever the `automation` mode; no clause says directors spawn at phase gates
+- [ ] Phase 2 is trunk-based: the release candidate is a commit on `main`, and a `release/*` branch is cut only when the release needs stabilising (freeze / certification), with every fix also landing on `main`
+- [ ] `/patch-notes` is run by release-manager in Phase 6, and community-manager writes the announcement from its output
 - [ ] Uses `AskUserQuestion` at phase transitions requiring user approval before proceeding
+- [ ] Phase 0 resolves `team.size`, and the skill requires a one-line active-set announcement before Phase 1
 - [ ] Phase 3 agents (qa-lead, devops-engineer, and optionally security-engineer, network-programmer) are explicitly stated to run in parallel
- [ ] Phase 6 (Deployment) is conditional on a GO decision from Phase 5
- [ ] security-engineer is described as conditional on online features / player data — not always spawned
+- [ ] Phase 6 (Deployment) is conditional on a GO decision from Phase 5 and on an explicit `AskUserQuestion` approval regardless of `modes.automation`
+- [ ] security-engineer is described as conditional on `platform.online` / `platform.multiplayer` and player data — not always spawned, and an absent key is asked about rather than read as `false`

 ---

@@ -33,34 +50,41 @@ NO-GO. Closes with a post-release monitoring plan.
 ### Case 1: Happy Path (Single-Player) — All phases complete, version deployed

 **Fixture:**
- `production/stage.txt` exists and contains a Production-or-later stage
+- Resolved config block: `review_mode: full`, `team.size: studio`, `automation: collaborative`
+- `project.stage` in `project.yaml` is `Release` (`/gate-check release` has passed)
 - Milestone acceptance criteria are all met (producer can confirm)
- No online features, no multiplayer, no player data collection
- All CI builds are clean on the current branch
- No open S1/S2 bugs
- `production/sprints/` contains the completed sprint stories for this milestone
+- `project.yaml` sets `platform.online: false` and `platform.multiplayer: false`; the game collects no player data
+- No freeze or platform certification is planned for this release
+- All CI builds are clean on `main`
+- No open S1/S2 bugs; all strings translated

 **Input:** `/team-release v1.0.0`

 **Expected behavior:**
-1. Phase 1: Spawns `producer` via Task; confirms all milestone acceptance criteria met; identifies any deferred scope; produces release authorization; presents to user; AskUserQuestion: user approves before Phase 2
-2. Phase 2: Spawns `release-manager` via Task; cuts release branch from agreed commit; bumps version numbers; invokes `/release-checklist`; freezes branch; output: branch name and checklist; AskUserQuestion: user approves before Phase 3
-3. Phase 3 (parallel): Issues Task calls simultaneously for `qa-lead` (regression suite, critical path sign-off) and `devops-engineer` (build artifacts, CI verification); security-engineer is NOT spawned (no online features); network-programmer is NOT spawned (no multiplayer); both complete successfully
-4. Phase 4: Verifies localization strings all translated; `analytics-engineer` verifies telemetry fires correctly on the release build; performance benchmarks pass; sign-off produced
-5. Phase 5: Spawns `producer` via Task; collects sign-offs from qa-lead, release-manager, devops-engineer; no open blocking issues; producer declares GO; AskUserQuestion: user sees GO decision and confirms deployment
-6. Phase 6: Spawns `release-manager` + `devops-engineer` (parallel); tags release in version control; invokes `/changelog`; deploys to staging; smoke test passes; deploys to production; simultaneously spawns `community-manager` to finalize patch notes via `/patch-notes v1.0.0` and prepare launch announcement
-7. Phase 7: release-manager generates release report; producer updates milestone tracking; qa-lead begins monitoring for regressions; community-manager publishes communication; analytics-engineer confirms live dashboards healthy
-8. Verdict: COMPLETE — release executed and deployed
+1. The stage check passes (`project.stage: Release`); before any spawn, one line announces the active set for `team.size: studio`
+2. Phase 1: Spawns `producer` via Agent; confirms all milestone acceptance criteria met; identifies any deferred scope; writes `production/releases/release-plan-v1.0.0.md`; AskUserQuestion: user approves before Phase 2
+3. Phase 2: Spawns `release-manager` via Agent; bumps version numbers on `main`, and that commit is the release candidate; finds no release checklist from Polish, so invokes `/release-checklist` (`production/releases/release-checklist-v1.0.0.md`); cuts no `release/*` branch, since nothing needs stabilising; AskUserQuestion: user approves before Phase 3
+4. Phase 3 (parallel): Issues Agent calls simultaneously for `qa-lead` (regression suite, critical path sign-off, `production/releases/qa-gate-v1.0.0.md`) and `devops-engineer` (build artifacts, CI verification, `production/releases/build-v1.0.0.md`); security-engineer is NOT spawned (`platform.online: false`, no player data) and network-programmer is NOT spawned (`platform.multiplayer: false`), and the Phase 3 output names each skip with its reason
+5. Phase 4: localization-lead verifies all strings are translated (`production/releases/localization-signoff-v1.0.0.md`); performance-analyst benchmarks the release build (`performance-signoff-v1.0.0.md`); `analytics-engineer` verifies telemetry fires correctly on the release build (`analytics-signoff-v1.0.0.md`) — each agent writes its own file
+6. Phase 5: Spawns `producer` via Agent; collects sign-offs from qa-lead, release-manager, devops-engineer and technical-director; no open blocking issues; producer declares GO (`production/releases/go-no-go-v1.0.0.md`)
+7. Phase 6: `AskUserQuestion` "Producer verdict is GO. Execute Phase 6 — tag, deploy to staging, deploy to production?" with [A] Yes, deploy / [B] Staging only — hold production / [C] Stop here; user selects [A]
+8. Phase 6: release-manager + devops-engineer tag the release, finalize the changelog via `/changelog`, deploy to staging, then production; in parallel release-manager finalizes patch notes via `/patch-notes v1.0.0` (`docs/patch-notes/v1.0.0.md`), and `community-manager` writes the launch announcement from them (`production/releases/announcement-v1.0.0.md`)
+9. Phase 7: release-manager generates the release report (`production/releases/release-report-v1.0.0.md`); producer updates milestone tracking; qa-lead monitors for regressions; community-manager publishes; analytics-engineer confirms live dashboards healthy
+10. Next steps: monitor dashboards for 48 hours; `/retrospective` if significant issues occurred
+11. Verdict: COMPLETE — release executed and deployed

 **Assertions:**
- [ ] Phase 3 qa-lead and devops-engineer Task calls are issued simultaneously, not sequentially
- [ ] security-engineer is NOT spawned when the game has no online features, multiplayer, or player data
- [ ] Phase 5 producer collects sign-offs from all required parties before declaring GO
- [ ] Phase 6 deployment only begins after GO decision is confirmed by the user
+- [ ] Active-set line naming `team.size: studio` appears before the first agent is spawned
+- [ ] Phase 2 cuts no `release/*` branch: the release candidate is the version-bump commit on `main`
+- [ ] Phase 3 qa-lead and devops-engineer Agent calls are issued simultaneously, not sequentially
+- [ ] security-engineer is NOT spawned when `platform.online` and `platform.multiplayer` are false and there is no player data, and the Phase 3 output says so by name (e.g. `security-engineer: not spawned — platform.online: false, platform.multiplayer: false, no player data`) — the skip is never silent
+- [ ] Each agent is told its own named output file — parallel Phase 3 and Phase 4 agents never share one — and the orchestrator confirms the file exists before treating the phase as done
+- [ ] Phase 5 producer collects sign-offs from qa-lead, release-manager, devops-engineer and technical-director before declaring GO
+- [ ] Phase 6 deployment only begins after the user picks [A] in the Phase 6 `AskUserQuestion`
 - [ ] `/changelog` is invoked by release-manager in Phase 6 (not written directly)
- [ ] `/patch-notes v1.0.0` is invoked by community-manager in Phase 6
+- [ ] `/patch-notes v1.0.0` is invoked by release-manager in Phase 6, and community-manager writes the announcement from its output — community-manager is never asked to run `/patch-notes`
 - [ ] Phase 7 monitoring plan includes a 48-hour post-release monitoring commitment
- [ ] Next steps recommend updating `production/stage.txt` to `Live` after successful deployment
+- [ ] No stop and no override question at the stage check, because `project.stage` reads `Release`; the skill writes neither `project.stage` nor `production/stage.txt`, and no post-launch stage value is invented
 - [ ] Verdict: COMPLETE appears in the final output

 ---
@@ -68,99 +92,102 @@ NO-GO. Closes with a post-release monitoring plan.
 ### Case 2: Go/No-Go: NO — S1 bug found in Phase 3, deployment skipped

 **Fixture:**
- Release candidate branch exists for v0.9.0
+- Resolved config block: `team.size: small`, `automation: collaborative`, `project.stage: Release`
+- The v0.9.0 release candidate is a commit on `main`
 - qa-lead discovers a previously unreported S1 crash in the main menu during Phase 3 regression testing
 - devops-engineer build is clean and artifacts are ready
- producer is aware of the S1 bug

 **Input:** `/team-release v0.9.0`

 **Expected behavior:**
-1. Phases 1–2 complete normally; release candidate is cut
+1. Phases 1–2 complete normally; the release candidate commit is identified
 2. Phase 3 (parallel): devops-engineer returns clean build sign-off; qa-lead returns with an S1 bug identified and regression suite failing; qa-lead declares quality gate: NOT PASSED
-3. Orchestrator surfaces the qa-lead result immediately: "QA-LEAD: S1 bug found — [crash description]. Quality gate: NOT PASSED."
-4. Phase 4 proceeds cautiously or is paused (AskUserQuestion: continue to Phase 4 or skip to Phase 5 for go/no-go?)
-5. Phase 5: Spawns `producer` via Task; producer receives qa-lead's NOT PASSED verdict; no S1 sign-off available; producer declares NO-GO with rationale: "S1 bug [ID] is open and unresolved. Releasing is not safe."
-6. AskUserQuestion: user is presented with the NO-GO decision and the S1 bug details; options: fix the bug and re-run, defer the release, or override (with documented rationale)
-7. Phase 6 (Deployment) is SKIPPED entirely — no branch tagging, no deploy to staging, no deploy to production
-8. community-manager is NOT spawned in Phase 6 (no deployment to announce)
-9. Skill ends with a partial report summarizing what was completed (Phases 1–5) and what was skipped (Phase 6) and why
-10. Verdict: BLOCKED — release not deployed
+3. At the Phase 3 → 4 transition the orchestrator writes qa-lead's full result in conversation — "QA-LEAD: S1 bug found — [crash description]. Quality gate: NOT PASSED." — and captures the decision via `AskUserQuestion`
+4. Phase 5: Spawns `producer` via Agent; producer receives qa-lead's NOT PASSED verdict; producer declares NO-GO with rationale: "S1 bug [ID] is open and unresolved. Releasing is not safe."
+5. Orchestrator surfaces "PRODUCER: NO-GO — [rationale]" and uses `AskUserQuestion` with options: fix the blocker and re-run the affected phase, defer the release, or override NO-GO with documented rationale
+6. Phase 6 (Deployment) is SKIPPED entirely — no tagging, no deploy to staging, no deploy to production
+7. Neither Phase 6 copy step runs — release-manager does not run `/patch-notes` and community-manager is NOT spawned (no deployment to announce)
+8. Skill ends with a partial report summarizing what was completed (Phases 1–5) and what was skipped (Phase 6) and why
+9. Verdict: BLOCKED — release not deployed

 **Assertions:**
 - [ ] qa-lead S1 bug finding is surfaced to the user immediately after Phase 3 completes — not suppressed until Phase 5
 - [ ] producer's NO-GO decision explicitly references the S1 bug and the quality gate result
 - [ ] Phase 6 Deployment is completely skipped when producer declares NO-GO
- [ ] community-manager is NOT spawned for patch notes or launch announcement on NO-GO
+- [ ] No patch notes or launch announcement are produced on NO-GO — `/patch-notes` is not run and community-manager is NOT spawned
 - [ ] The partial report clearly states which phases completed and which were skipped, with reasons
 - [ ] Verdict: BLOCKED (not COMPLETE) when deployment is skipped due to NO-GO
 - [ ] AskUserQuestion offers the user resolution options (fix and re-run / defer / override with rationale)
- [ ] Override path (if chosen) requires user to provide a documented rationale before proceeding to Phase 6
+- [ ] Override path (if chosen) asks for a written justification and embeds it as an "Override Justification" field in the record before any Phase 6 action

 ---

 ### Case 3: Security Audit for Online Game — security-engineer is spawned in Phase 3

 **Fixture:**
- Game has multiplayer features and stores player account data
+- Resolved config block: `review_mode: full`, `team.size: studio`, `automation: collaborative`, `project.stage: Release`
+- `project.yaml` sets `platform.multiplayer: true` and `platform.online: true`; the game stores player account data
 - Release candidate exists for v2.1.0
 - qa-lead and devops-engineer both return clean sign-offs
- security-engineer audit is required per team composition rules

 **Input:** `/team-release v2.1.0`

 **Expected behavior:**
 1. Phases 1–2 complete normally
-2. Phase 3 (parallel): Orchestrator detects that the game has online/multiplayer features and player data; issues Task calls simultaneously for `qa-lead`, `devops-engineer`, AND `security-engineer`; also spawns `network-programmer` for netcode stability sign-off
+2. Phase 3 (parallel): Orchestrator reads `platform.multiplayer: true` and `platform.online: true` from `project.yaml` and notes the stored player data; issues Agent calls simultaneously for `qa-lead`, `devops-engineer`, `security-engineer` and `network-programmer`
 3. security-engineer conducts pre-release security audit: reviews authentication flows, anti-cheat presence, data privacy compliance; returns sign-off
 4. network-programmer verifies lag compensation, reconnect handling, and bandwidth under load; returns sign-off
 5. All four Phase 3 agents complete; their results are collected before Phase 4 begins
-6. Phase 5: producer collects sign-offs from all four Phase 3 agents (qa-lead, devops-engineer, security-engineer, network-programmer) before making the go/no-go call
+6. Phase 5: producer collects sign-offs from qa-lead, release-manager, devops-engineer, security-engineer, network-programmer and technical-director before making the go/no-go call
 7. Remaining phases proceed normally to COMPLETE

 **Assertions:**
 - [ ] security-engineer IS spawned in Phase 3 when the game has online features, multiplayer, or player data — this is not skipped
 - [ ] network-programmer IS spawned in Phase 3 when the game has multiplayer
- [ ] All four Phase 3 Task calls (qa-lead, devops-engineer, security-engineer, network-programmer) are issued simultaneously
+- [ ] All four Phase 3 Agent calls (qa-lead, devops-engineer, security-engineer, network-programmer) are issued simultaneously
 - [ ] security-engineer audit covers authentication, anti-cheat, and data privacy compliance
- [ ] Phase 5 producer sign-off collection includes security-engineer (four parties, not two)
+- [ ] Phase 5 producer sign-off collection includes security-engineer and network-programmer alongside qa-lead, release-manager, devops-engineer and technical-director
 - [ ] Phase 6 deployment does not begin until security-engineer has signed off
 - [ ] Skill does NOT treat security-engineer as optional for a game with player data

 ---

-### Case 4: Localization Miss — Untranslated strings block the ship
+### Case 4: Localization Miss — Untranslated strings reach the go/no-go call

 **Fixture:**
+- Resolved config block: `team.size: studio`, `automation: collaborative`, `project.stage: Release`
+- `project.yaml` sets `platform.online: false` and `platform.multiplayer: false`; no player data
 - Release candidate exists for v1.2.0
 - Phase 3 (qa-lead, devops-engineer) complete with clean sign-offs
- Phase 4: localization verification detects 47 untranslated strings in the French locale (a supported language in the game's localization scope)
- localization-lead is available as a delegatable agent
+- Phase 4: localization-lead finds 47 untranslated strings in the French locale (a supported language) and returns it as a BLOCKED/CONCERNS item
+- producer judges the miss release-blocking and declares NO-GO

 **Input:** `/team-release v1.2.0`

 **Expected behavior:**
 1. Phases 1–3 complete with clean sign-offs
-2. Phase 4: Localization verification step detects untranslated strings; identifies 47 strings in French locale; localization-lead (if available) is spawned to assess the severity
-3. Orchestrator surfaces: "LOCALIZATION MISS: 47 untranslated strings found in French locale. Localization sign-off is required before shipping."
-4. AskUserQuestion: options presented — (a) Fix translations and re-run Phase 4, (b) Remove French locale from this release, (c) Ship as-is with a known issues note
-5. If user selects (a): Phase 4 is re-run after translations are provided; skill waits for localization sign-off
-6. Phase 5 go/no-go does NOT proceed while localization sign-off is outstanding
-7. Ship is blocked (Phase 6 not entered) until localization issue is resolved or explicitly waived
+2. Phase 4: the translation check is delegated to localization-lead (active at `studio`); its sign-off is written to `production/releases/localization-signoff-v1.2.0.md` and the orchestrator confirms the file exists
+3. At the Phase 4 → 5 transition the orchestrator writes the localization finding in conversation and captures the decision via `AskUserQuestion` — it does not auto-advance
+4. Phase 5: producer evaluates the untranslated strings as an open issue and declares NO-GO
+5. Orchestrator surfaces "PRODUCER: NO-GO — [rationale naming the untranslated French strings]" and offers via `AskUserQuestion`: fix the blocker and re-run the affected phase / defer the release / override NO-GO with documented rationale
+6. Phase 6 is skipped entirely; a partial report lists Phases 1–5 as completed and Phase 6 as skipped with the reason
+7. Verdict: BLOCKED — release not deployed

 **Assertions:**
- [ ] Localization verification in Phase 4 detects untranslated strings and counts them (not just "some strings missing")
- [ ] Untranslated strings for a supported locale block the pipeline before Phase 5
- [ ] AskUserQuestion is used to offer the user resolution choices — the skill does not auto-waive
- [ ] Phase 5 go/no-go is NOT called while localization sign-off is pending
- [ ] If user chooses to re-run Phase 4: the skill does not require restarting from Phase 1
- [ ] If user explicitly waives (ships as-is): the waiver is documented in the release report (Phase 7) as a known issue
- [ ] Skill does NOT fabricate translated strings to unblock itself
+- [ ] Phase 4 delegates the translation check to localization-lead when it is in the active set
+- [ ] The localization finding is presented at the Phase 4 → 5 transition via `AskUserQuestion` before the go/no-go runs
+- [ ] The producer's NO-GO rationale names the untranslated-strings issue
+- [ ] The resolution options include re-running the affected phase — the skill does not require restarting from Phase 1
+- [ ] If the user overrides, the written justification is embedded in the record before any Phase 6 action
+- [ ] The orchestrator writes no files itself — it does not produce translations to unblock the release
+- [ ] Verdict is BLOCKED and Phase 6 does not run on NO-GO

 ---

 ### Case 5: No Argument — Skill infers version or asks

+In both variants `project.stage` is `Release`.
+
 **Fixture (variant A — milestone data present):**
 - `production/milestones/` exists with a milestone file; most recent milestone is "v1.1.0 — Gold"
 - `production/session-state/active.md` references a version or milestone
@@ -173,13 +200,13 @@ NO-GO. Closes with a post-release monitoring plan.
 **Input:** `/team-release` (no argument)

 **Expected behavior (variant A):**
-1. Phase 1: No argument provided; reads `production/session-state/active.md`; reads most recent milestone file in `production/milestones/`
+1. Argument check: no version provided; reads `production/session-state/active.md` and the most recent milestone file in `production/milestones/`
 2. Infers v1.1.0 as the target version; reports "No version argument provided — inferred v1.1.0 from milestone data. Proceeding."
-3. Confirms with AskUserQuestion before beginning Phase 1 proper: "Releasing v1.1.0. Is this correct?"
+3. Confirms with AskUserQuestion before beginning Phase 1: "Releasing v1.1.0. Is this correct?"
 4. Proceeds as if `/team-release v1.1.0` was the input

 **Expected behavior (variant B):**
-1. Phase 1: No argument provided; reads available state files — no version discoverable
+1. Argument check: no version provided; reads available state files — no version discoverable
 2. Uses AskUserQuestion: "What version number should be released? (e.g., v1.0.0)"
 3. Waits for user input before proceeding

@@ -192,24 +219,61 @@ NO-GO. Closes with a post-release monitoring plan.

 ---

+### Case 6: Stage Still Polish — Stops Before Phase 1, Nothing Spawned
+
+**Fixture:**
+- Resolved config block: `review_mode: full`, `team.size: studio`, `automation: autonomous`, `project.stage: Polish`
+- `/gate-check release` has not been run; a release candidate exists for v1.0.0
+
+**Input:** `/team-release v1.0.0`
+
+**Expected behavior (variant A — the user stops):**
+1. Phase 0 resolves `project.stage: Polish`; the stage check stops before Phase 1: "The release readiness gate has not passed (project.stage: Polish) — run `/gate-check release` first."
+2. `AskUserQuestion` offers `[A] Stop — I'll run /gate-check release (recommended)` / `[B] Proceed anyway — override the stage check` — asked even though `automation` is `autonomous`
+3. User picks `[A]`: no agent is spawned, no file is written, nothing is tagged or deployed
+4. Verdict: BLOCKED — release gate not passed
+
+**Expected behavior (variant B — the user overrides):**
+1. Same stop and question; user picks `[B]` and, asked why, answers "cert window closes Friday"
+2. The run continues to Phase 1 with the override in the producer's brief
+3. The go/no-go record (`production/releases/go-no-go-v1.0.0.md`) and the final report carry `Stage override: project.stage was Polish — release gate not passed; the user chose to proceed: cert window closes Friday`
+4. `project.stage` still reads `Polish` at the end of the run
+
+**Assertions:**
+- [ ] No `Agent` call is issued before the stage-check question is answered
+- [ ] The stop message names `/gate-check release` as the step to run first
+- [ ] The question is asked in `autonomous` mode — the override is never taken automatically
+- [ ] On `[A]` the verdict is BLOCKED and no agent is spawned at all (not even release-manager)
+- [ ] On `[B]` the override and its reason appear in the go/no-go record and in the final report
+- [ ] The skill writes neither `project.stage` nor `production/stage.txt` in either variant
+
+---
+
 ## Protocol Compliance

- [ ] `AskUserQuestion` used at each phase transition gate (post-Phase 1, post-Phase 2, post-Phase 3/4 if issues, post-Phase 5 go/no-go)
- [ ] Phase 3 agents are always issued as parallel Task calls — qa-lead and devops-engineer are never sequential
- [ ] security-engineer is conditionally spawned based on game features — never silently skipped when features are present
- [ ] File Write Protocol: orchestrator never calls Write/Edit directly — all writes are delegated to sub-agents or sub-skills
- [ ] Phase 6 Deployment is strictly conditional on a GO verdict from Phase 5 — never auto-triggered
+- [ ] At the default `team.size: individual`, the run opens with `Active set (team.size: individual): release-manager.` and a `Not spawned this run:` line naming every other agent the pipeline names, consulted through release-manager — before any agent is spawned
+- [ ] In `collaborative` mode, `AskUserQuestion` used at each phase transition gate (post-Phase 1, post-Phase 2, post-Phase 3, post-Phase 4, post-Phase 5 go/no-go)
+- [ ] Phase 3 agents in the active set are always issued as parallel Agent calls — qa-lead and devops-engineer are never sequential
+- [ ] security-engineer is conditionally spawned from `platform.online` / `platform.multiplayer` and player data — never silently skipped: an absent key is asked about, and a skip is named in the Phase 3 output
+- [ ] At `review_mode: lean` or `solo`, technical-director is not spawned for the Phase 5 sign-off, and the go/no-go record says `technical-director sign-off: not run (review_mode: <mode>)` rather than listing it as given
+- [ ] A technical-director `NOT ASSESSED [missing input]` answer is recorded as such in the go/no-go record and never counted as a sign-off
+- [ ] When a `release/*` branch is cut to stabilise a release, it takes bug fixes only and every fix also lands on `main`
+- [ ] File Write Protocol: orchestrator never calls Write/Edit directly — sub-agents write their named paths under the bounded exception, sub-skills ask before writing
+- [ ] Phase 6 Deployment is strictly conditional on a GO verdict from Phase 5 and an explicit `AskUserQuestion` approval — never auto-triggered, including in `autonomous` mode
 - [ ] Error recovery: any BLOCKED agent is surfaced immediately before continuing to dependent phases
- [ ] Partial reports are always produced if any phase fails or the pipeline is halted (Case 2)
- [ ] Verdict: COMPLETE only when deployment completes; BLOCKED when go/no-go is NO or a hard blocker is unresolved
- [ ] Next steps always include 48-hour post-release monitoring, `/retrospective` recommendation, and `production/stage.txt` update to `Live`
+- [ ] A phase whose named artifact is missing on disk is treated as failed, not done
+- [ ] Partial reports are always produced if any phase fails or the pipeline is halted (Cases 2 and 4)
+- [ ] Verdict: COMPLETE only when deployment completes; BLOCKED when the stage check stops the run, go/no-go is NO, or a hard blocker is unresolved
+- [ ] Stage check: when `project.stage` is not `Release`, nothing is spawned until the user answers the stop question; proceeding takes the explicit `[B]` override, which is recorded (Case 6)
+- [ ] Next steps always include 48-hour post-release monitoring and a `/retrospective` recommendation — never a direct `project.stage` write

 ---

 ## Coverage Notes

 - Phase 7 post-release actions (release report, milestone tracking, community publishing, dashboard monitoring) are validated implicitly by Case 1. No separate edge case is required as Phase 7 is non-gated and does not have a blocking failure mode.
- The "devops-engineer build fails" path is not separately tested — it would surface as a BLOCKED result in Phase 3 and follow the standard error recovery protocol (surface → assess → AskUserQuestion options). This is validated structurally by the Static Assertions error recovery check.
- The parallel Phase 4 path (localization + performance + analytics simultaneously with Phase 3) is a documented option in the skill ("can run in parallel with Phase 3 if resources available"). Case 4 tests Phase 4 as a sequential gate; the parallel variant is left to the skill's implementation judgment.
- The `network-programmer` sign-off path for multiplayer is validated as part of Case 3 rather than a separate case, as it follows the same parallel-spawn pattern as security-engineer.
- The "override NO-GO with documented rationale" path in Case 2 is referenced but not exhaustively tested — it is an escape hatch that the skill must support, and its existence is validated by the AskUserQuestion options assertion in Case 2.
+- The "devops-engineer build fails" path is not separately tested — it would surface as a BLOCKED result in Phase 3 and follow the standard error recovery protocol (surface → assess → AskUserQuestion options).
+- The parallel Phase 4 path (running alongside Phase 3 "if resources available") is left to the skill's judgment; Case 4 tests Phase 4 as a sequential phase.
+- The `[B] Staging only — hold production` Phase 6 option is not separately tested.
+- A release that needs stabilising (a freeze or platform certification, so a `release/*` branch is cut) is not given its own case; the rule is asserted in Protocol Compliance.
+- The "override NO-GO with documented rationale" path is checked for its justification step in Cases 2 and 4 but not followed through a full deployment.
@@ -7,10 +7,15 @@ Coordinates ux-designer, ui-programmer, art-director, the engine UI specialist,
 and accessibility-specialist through five structured phases: Context Gathering +
 UX Spec (Phase 1a/1b) → UX Review Gate (Phase 1c) → Visual Design (Phase 2) →
 Implementation (Phase 3) → Review in parallel (Phase 4) → Polish (Phase 5).
-Uses `AskUserQuestion` at each phase transition. Delegates all file writes to
-sub-agents and sub-skills (`/ux-design`, `ui-programmer`). Produces a summary report
-with verdict COMPLETE / BLOCKED and handoffs to `/ux-review`, `/code-review`,
-`/team-polish`.
+Phase 0 resolves `review_mode`, `automation` and `team.size` and the skill announces
+the active set before any spawn — the default `individual` spawns ui-programmer +
+ux-designer, `small` adds accessibility-specialist + art-director, `studio` adds the
+engine UI specialist and an adversarial Phase 4 review. Phase 1a reports each of its five inputs as present or ABSENT,
+and a missing `design/accessibility-requirements.md` is carried forward as
+`Accessibility: NOT ASSESSED`. Uses `AskUserQuestion` at each phase transition.
+Delegates all file writes to sub-agents and sub-skills (`/ux-design`,
+`ui-programmer`). Produces a summary report with verdict COMPLETE / BLOCKED and
+handoffs to `/ux-review`, `/code-review`, `/team-polish`.

 ---

@@ -19,13 +24,17 @@ with verdict COMPLETE / BLOCKED and handoffs to `/ux-review`, `/code-review`,
 - [ ] Has required frontmatter fields: `name`, `description`, `argument-hint`, `user-invocable`, `allowed-tools`
 - [ ] Has ≥2 phase headings (Phase 1a through Phase 5 are all present)
 - [ ] Contains verdict keywords: COMPLETE, BLOCKED
- [ ] Contains "May I write" or "File Write Protocol" — writes delegated to sub-agents and sub-skills, orchestrator does not write files directly
+- [ ] File Write Protocol: sub-agents write under the bounded exception (named path, new artifact under `production/`, `docs/` or `tests/`, gated phase) and ask outside it; sub-skills (`/ux-design`) ask before writing; the orchestrator does not write files directly; implementation files (code, shaders, audio, assets) are outside it — each agent lists the files it will create or change, and the skill asks once for the set before any is written
+- [ ] Names a destination per agent under `production/ui/[feature-name]/`: `visual-design.md` (art-director, Phase 2), `engine-notes.md` (engine UI specialist), `review-[agent].md` (each Phase 4 reviewer, one file each)
+- [ ] Defines a phase gate as a decision point the pipeline itself lists, whatever the `automation` mode, and claims no director spawn at phase gates
 - [ ] Has a next-step handoff at the end (references `/ux-review`, `/code-review`, `/team-polish`)
- [ ] Error Recovery Protocol section is present with all four recovery steps
- [ ] Uses `AskUserQuestion` at phase transitions for user approval before proceeding
+- [ ] Error Recovery Protocol section is present: verify a named artifact is on disk, surface BLOCKED immediately, always produce a partial report, full procedure (surface → assess → options → partial report) in `.claude/docs/error-recovery-protocol.md`
+- [ ] Uses `AskUserQuestion` at phase transitions for user approval before proceeding (`collaborative` mode)
+- [ ] Phase 0 resolves `team.size`, and the skill requires a one-line active-set announcement before any spawn
 - [ ] Phase 4 is explicitly marked as parallel (ux-designer, art-director, accessibility-specialist)
- [ ] UX Review Gate (Phase 1c) is defined as a blocking gate — skill must not proceed to Phase 2 without APPROVED verdict
+- [ ] UX Review Gate (Phase 1c) is defined as a blocking gate — skill must not proceed to Phase 2 without APPROVED verdict, except by an explicit user override of NEEDS REVISION or NOT ASSESSED, which the final report records
 - [ ] Team Composition lists all five roles (ux-designer, ui-programmer, art-director, engine UI specialist, accessibility-specialist)
+- [ ] Engine UI specialist is read from `specialists.ui` in `project.yaml` (falling back to `.claude/docs/technical-preferences.md`), and `specialists.ui: null` is treated as unset
 - [ ] References the interaction pattern library (`design/ux/interaction-patterns.md`) — ui-programmer must use existing patterns
 - [ ] Phase 1a reads `design/accessibility-requirements.md` before design begins

@@ -36,30 +45,35 @@ with verdict COMPLETE / BLOCKED and handoffs to `/ux-review`, `/code-review`,
 ### Case 1: Happy Path — Full pipeline from UX spec through polish succeeds

 **Fixture:**
+- Resolved config block: `review_mode: full`, `team.size: studio`, `automation: collaborative`
 - `design/gdd/game-concept.md` exists with platform targets and intended audience
 - `design/player-journey.md` exists
 - `design/ux/interaction-patterns.md` exists with relevant patterns
- `design/accessibility-requirements.md` exists with committed tier (e.g., Enhanced)
- Engine UI specialist configured in `.claude/docs/technical-preferences.md`
+- `design/accessibility-requirements.md` exists with committed tier (e.g., Standard)
+- `engine.name` in `project.yaml` is Godot and `specialists.ui` is `godot-specialist`

 **Input:** `/team-ui inventory screen`

 **Expected behavior:**
-1. Phase 1a — orchestrator reads game-concept.md, player-journey.md, relevant GDD UI sections, interaction-patterns.md, accessibility-requirements.md; summarizes a brief for the ux-designer
-2. Phase 1b — `/ux-design inventory-screen` invoked (or ux-designer spawned directly); produces `design/ux/inventory-screen.md` using `ux-spec.md` template; `AskUserQuestion` confirms spec before review
-3. Phase 1c — `/ux-review design/ux/inventory-screen.md` invoked; returns APPROVED; gate passed, proceed to Phase 2
-4. Phase 2 — art-director spawned; reviews full UX spec (not only wireframes); applies visual treatment; verifies color contrast; produces visual design spec with asset manifest; `AskUserQuestion` confirms before Phase 3
-5. Phase 3 — engine UI specialist spawned first (read from technical-preferences.md); produces implementation notes for ui-programmer; ui-programmer spawned with UX spec + visual spec + engine notes; implementation produced; interaction-patterns.md updated if new patterns introduced
-6. Phase 4 — ux-designer, art-director, accessibility-specialist spawned in parallel; all three return results before Phase 5
-7. Phase 5 — review feedback addressed; animations verified skippable; UI sounds confirmed through audio event system; interaction-patterns.md final check; verdict: COMPLETE
-8. Summary report: UX spec APPROVED, visual design COMPLETE, implementation COMPLETE, accessibility COMPLIANT, all input methods supported, pattern library updated, verdict: COMPLETE
+1. Before any spawn, one line announces the active set for `team.size: studio`
+2. Phase 1a — orchestrator reads game-concept.md, player-journey.md, relevant GDD UI sections, interaction-patterns.md, accessibility-requirements.md; reports each input as present or ABSENT; summarizes a brief for the ux-designer
+3. Phase 1b — `/ux-design inventory-screen` invoked (or ux-designer spawned directly); produces `design/ux/inventory-screen.md` using `ux-spec.md` template; `AskUserQuestion` confirms spec before review
+4. Phase 1c — `/ux-review design/ux/inventory-screen.md` invoked; returns APPROVED; gate passed, proceed to Phase 2
+5. Phase 2 — art-director spawned; reviews full UX spec (not only wireframes); applies visual treatment; verifies color contrast; produces visual design spec with asset manifest; `AskUserQuestion` confirms before Phase 3
+6. Phase 3 — `godot-specialist` (from `specialists.ui`) spawned first; produces implementation notes for ui-programmer; ui-programmer spawned with UX spec + visual spec + engine notes; implementation produced; interaction-patterns.md updated if new patterns introduced
+7. Phase 4 — ux-designer, art-director, accessibility-specialist spawned in parallel, each told to find where the implementation fails its spec rather than confirm it matches (the `studio` adversarial pass); all three return results before Phase 5
+8. Phase 5 — review feedback addressed; animations verified skippable; UI sounds confirmed through audio event system; interaction-patterns.md final check
+9. Summary report: UX spec status, UX review verdict, visual design status, implementation status, accessibility compliance, input method support, pattern library status; verdict: COMPLETE

 **Assertions:**
- [ ] Phase 1a reads all five sources before briefing ux-designer
+- [ ] Active-set line naming `team.size: studio` appears before the first agent is spawned
+- [ ] Phase 1a reads all five sources and lists each as present or ABSENT before briefing ux-designer
 - [ ] UX Review Gate checked before Phase 2 — Phase 2 does NOT begin until APPROVED
 - [ ] Art-director in Phase 2 reviews full spec, not just wireframe images
- [ ] Engine UI specialist spawned before ui-programmer in Phase 3
+- [ ] Engine UI specialist is taken from `specialists.ui` and spawned before ui-programmer in Phase 3
+- [ ] ui-programmer lists the files it will create or change, and writes none before the one ask for that set is answered yes
 - [ ] Phase 4 agents launched simultaneously (ux-designer, art-director, accessibility-specialist)
+- [ ] At `team.size: studio`, Phase 4's prompts are adversarial and the summary report says the adversarial pass ran
 - [ ] All file writes delegated to sub-agents and sub-skills
 - [ ] Verdict COMPLETE in final summary report
 - [ ] Next steps include `/ux-review`, `/code-review`, `/team-polish`
@@ -69,6 +83,7 @@ with verdict COMPLETE / BLOCKED and handoffs to `/ux-review`, `/code-review`,
 ### Case 2: UX Review Gate — Spec fails review; skill halts before implementation

 **Fixture:**
+- Resolved config block: `automation: collaborative` (any `team.size` — ux-designer is active at every size)
 - `design/ux/inventory-screen.md` produced by Phase 1b
 - `/ux-review` returns verdict NEEDS REVISION with specific concerns flagged (e.g., gamepad navigation flow incomplete, contrast ratio below minimum)

@@ -89,10 +104,20 @@ with verdict COMPLETE / BLOCKED and handoffs to `/ux-review`, `/code-review`,
 - [ ] Phase 2 does NOT begin while UX review verdict is NEEDS REVISION
 - [ ] `AskUserQuestion` presents the specific flagged concerns before offering options
 - [ ] User must make a conscious choice to override — skill does not assume override
- [ ] If user accepts risk, NEEDS REVISION concern is documented in the final report
+- [ ] If user accepts risk, the final report records the override: the NEEDS REVISION verdict, the concerns left open, and that the user chose to proceed
 - [ ] Revision-and-re-review loop is offered (not just a one-shot failure)
 - [ ] Skill does NOT discard the produced UX spec on review failure

+**Variant B — `/ux-review` returns NOT ASSESSED:**
+- Fixture as above, except `design/accessibility-requirements.md` is absent and the other review dimensions find no gaps, so `/ux-review` returns NOT ASSESSED (accessibility: no committed tier)
+- Expected: Phase 2 does not begin; `AskUserQuestion` names the unassessed dimension and its missing input (`/ux-design accessibility`), with options to produce that input and re-run the review, or to proceed consciously; if the user proceeds, the final report records the NOT ASSESSED override and Phase 4 still reports `Accessibility: NOT ASSESSED — no committed tier (design/accessibility-requirements.md absent)`
+
+**Assertions (variant B):**
+- [ ] Phase 2 does NOT begin on NOT ASSESSED without an explicit user decision — it blocks like NEEDS REVISION
+- [ ] The prompt names the dimension `/ux-review` could not assess and the input that would make it checkable, not spec revisions
+- [ ] The skill does not re-run `/ux-review` against the same missing input and treat the result as new
+- [ ] An override is recorded in the final report with the NOT ASSESSED verdict and the unassessed dimension
+
 ---

 ### Case 3: No Argument — Usage guidance shown
@@ -105,12 +130,12 @@ with verdict COMPLETE / BLOCKED and handoffs to `/ux-review`, `/code-review`,
 **Expected behavior:**
 1. Skill detects no argument provided
 2. Outputs usage message explaining the required argument (UI feature description)
-3. Provides an example invocation: `/team-ui [UI feature description]`
+3. Shows the invocation format `/team-ui [UI feature description] [--review full|lean|solo]` with examples (`inventory screen`, `main menu`, `combat HUD`)
 4. Skill exits without spawning any subagents or reading any project files

 **Assertions:**
 - [ ] Skill does NOT spawn any subagents when no argument is given
- [ ] Usage message includes the argument-hint format from frontmatter
+- [ ] Usage message shows the full argument-hint: `/team-ui [UI feature description] [--review full|lean|solo]`
 - [ ] At least one example of a valid invocation is shown
 - [ ] No UX spec files or GDDs read before failing
 - [ ] Verdict is NOT shown (pipeline never starts)
@@ -120,25 +145,26 @@ with verdict COMPLETE / BLOCKED and handoffs to `/ux-review`, `/code-review`,
 ### Case 4: Accessibility Parallel Review — Phase 4 runs three streams simultaneously

 **Fixture:**
+- Resolved config block: `review_mode: full`, `team.size: small`, `automation: collaborative`
 - `design/ux/inventory-screen.md` exists (APPROVED)
 - Visual design spec complete
 - Implementation complete
- `design/accessibility-requirements.md` committed tier: Enhanced
+- `design/accessibility-requirements.md` committed tier: Standard

 **Input:** `/team-ui inventory screen` (resuming from Phase 3 complete)

 **Expected behavior:**
 1. Phase 4 begins after implementation is confirmed complete
-2. Three Task calls issued simultaneously: ux-designer, art-director, accessibility-specialist
+2. Three Agent calls issued simultaneously: ux-designer, art-director, accessibility-specialist
 3. Each stream operates independently:
   - ux-designer: verifies implementation matches wireframes, tests keyboard-only and gamepad-only navigation, checks accessibility features function
   - art-director: verifies visual consistency with art bible at minimum and maximum supported resolutions
-   - accessibility-specialist: audits against the Enhanced accessibility tier in `design/accessibility-requirements.md`; any violation flagged as a blocker
+   - accessibility-specialist: audits against the Standard accessibility tier in `design/accessibility-requirements.md`; any violation flagged as a blocker
 4. Skill waits for all three results before proceeding to Phase 5
 5. `AskUserQuestion` presents all three review results before Phase 5 begins

 **Assertions:**
- [ ] All three Task calls issued before any result is awaited (parallel, not sequential)
+- [ ] All three Agent calls issued before any result is awaited (parallel, not sequential)
 - [ ] Phase 5 does NOT begin until all three Phase 4 agents have returned
 - [ ] Accessibility-specialist explicitly reads `design/accessibility-requirements.md` for the committed tier
 - [ ] Accessibility violations flagged as BLOCKING (not merely advisory)
@@ -150,6 +176,7 @@ with verdict COMPLETE / BLOCKED and handoffs to `/ux-review`, `/code-review`,
 ### Case 5: Missing Interaction Pattern Library — Skill notes the gap rather than inventing patterns

 **Fixture:**
+- Resolved config block: `automation: collaborative` (any `team.size`)
 - `design/ux/interaction-patterns.md` does NOT exist
 - All other required files present

@@ -160,7 +187,7 @@ with verdict COMPLETE / BLOCKED and handoffs to `/ux-review`, `/code-review`,
 2. Skill surfaces the gap: "interaction-patterns.md does not exist — no existing patterns to reuse"
 3. `AskUserQuestion` presented with options:
   - (a) Run `/ux-design patterns` first to establish the pattern library, then continue
-   - (b) Proceed without the pattern library — ux-designer will document new patterns as they are created
+   - (b) Proceed without the pattern library — ui-programmer will treat all patterns created as new and add each to a new `design/ux/interaction-patterns.md` at completion
 4. Skill does NOT invent or assume patterns from other sources
 5. If user chooses (b): ui-programmer is explicitly instructed to treat all patterns created as new and to add each to a new `design/ux/interaction-patterns.md` at completion
 6. Final report notes that interaction-patterns.md was created (or is still absent if user skipped)
@@ -177,8 +204,12 @@ with verdict COMPLETE / BLOCKED and handoffs to `/ux-review`, `/code-review`,

 ## Protocol Compliance

- [ ] `AskUserQuestion` used at each phase transition — user approves before pipeline advances
- [ ] UX Review Gate (Phase 1c) is blocking — Phase 2 cannot begin without APPROVED or explicit user override
+- [ ] At the default `team.size: individual`, the run opens with an `Active set (team.size: individual): ui-programmer + ux-designer` line and a `Not spawned this run:` line naming art-director, accessibility-specialist and the engine UI specialist — before any agent is spawned
+- [ ] In `collaborative` mode, `AskUserQuestion` used at each phase transition — user approves before pipeline advances
+- [ ] UX Review Gate (Phase 1c) is blocking — Phase 2 cannot begin without APPROVED, or an explicit user override of a NEEDS REVISION or NOT ASSESSED verdict that the final report records
+- [ ] When `design/accessibility-requirements.md` is absent, Phase 4 reports `Accessibility: NOT ASSESSED — no committed tier (design/accessibility-requirements.md absent)` and never reports the accessibility gate as passed
+- [ ] When no engine is configured, the engine UI specialist is skipped and the run output records `Engine validation: NOT ASSESSED — no engine configured`
+- [ ] When the accessibility gate or the engine validation was NOT ASSESSED, the verdict names each (`COMPLETE — [accessibility | engine validation] NOT ASSESSED ([reason])`) — never a plain COMPLETE
 - [ ] All file writes delegated to sub-agents and sub-skills — orchestrator does not call Write or Edit directly
 - [ ] Phase 4 agents launched in parallel per skill spec
 - [ ] Error Recovery Protocol followed: surface → assess → offer options → partial report
@@ -193,9 +224,11 @@ with verdict COMPLETE / BLOCKED and handoffs to `/ux-review`, `/code-review`,
 - The HUD-specific path (`/ux-design hud` + `hud-design.md` template + visual budget check in Phase 5)
  is not separately tested here; it shares the same phase structure but uses different templates.
 - The "Update in place" path for interaction-patterns.md (new pattern added during implementation)
-  is exercised implicitly in Case 1 Step 5 — a dedicated fixture with a known new pattern would
+  is exercised implicitly in Case 1 Phase 3 — a dedicated fixture with a known new pattern would
  strengthen coverage.
- Engine UI specialist unavailable (no engine configured) — skill spec states "skip if no engine
-  configured"; this path is asserted in Case 1 but not given a dedicated fixture.
- The NEEDS REVISION acceptance-risk override (Case 2 option b) requires the override to be
-  explicitly documented in the report; this is asserted but not further tested for downstream effects.
+- Engine UI specialist unavailable (no engine configured) is asserted in Protocol Compliance but
+  not given a dedicated fixture; a missing accessibility-requirements file is exercised at the
+  Phase 1c gate by Case 2 variant B.
+- The NEEDS REVISION and NOT ASSESSED overrides (Case 2, both variants) must be recorded in
+  the final report; this is asserted but not further tested for downstream effects.
+- A MAJOR REVISION NEEDED verdict from `/ux-review` is not given a case.