添加 claude code game studios 到项目
This commit is contained in:
panw
210
CCGS Skill Testing Framework/skills/team/team-audio.md
Normal file
210
CCGS Skill Testing Framework/skills/team/team-audio.md
Normal file
@@ -0,0 +1,210 @@
|
||||
# Skill Test Spec: /team-audio
|
||||
|
||||
## Skill Summary
|
||||
|
||||
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.
|
||||
|
||||
---
|
||||
|
||||
## Static Assertions (Structural)
|
||||
|
||||
- [ ] Has required frontmatter fields: `name`, `description`, `argument-hint`, `user-invocable`, `allowed-tools`
|
||||
- [ ] 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
|
||||
- [ ] 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
|
||||
- [ ] 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`
|
||||
|
||||
---
|
||||
|
||||
## Test Cases
|
||||
|
||||
### Case 1: Happy Path — All steps complete, audio design document saved
|
||||
|
||||
**Fixture:**
|
||||
- GDD for the target feature exists at `design/gdd/combat.md`
|
||||
- Sound bible exists at `design/gdd/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
|
||||
|
||||
**Assertions:**
|
||||
- [ ] 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
|
||||
- [ ] 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)
|
||||
- [ ] Summary includes audio event count and estimated asset count
|
||||
- [ ] No files are written by the orchestrator directly
|
||||
- [ ] Verdict is COMPLETE after document delivery
|
||||
|
||||
---
|
||||
|
||||
### Case 2: Accessibility Gap — Critical gameplay audio event has no visual fallback
|
||||
|
||||
**Fixture:**
|
||||
- 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
|
||||
- accessibility-specialist reviews the event list and finds "EnemyNearbyAlert" has no visual fallback (no on-screen indicator, no subtitle, no controller rumble specified)
|
||||
|
||||
**Input:** `/team-audio stealth` (Step 2 scenario)
|
||||
|
||||
**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:
|
||||
- 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
|
||||
|
||||
**Assertions:**
|
||||
- [ ] Accessibility gap is labeled BLOCKING (not advisory) in the report
|
||||
- [ ] The specific event name ("EnemyNearbyAlert") and the nature of the gap are stated
|
||||
- [ ] `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
|
||||
|
||||
---
|
||||
|
||||
### Case 3: No Argument — Usage guidance or design doc inference
|
||||
|
||||
**Fixture:**
|
||||
- Any project state
|
||||
|
||||
**Input:** `/team-audio` (no argument)
|
||||
|
||||
**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`)"
|
||||
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
|
||||
- [ ] Skill does NOT attempt to infer a feature from existing design docs without user direction
|
||||
- [ ] No `AskUserQuestion` is used — output is direct guidance
|
||||
|
||||
---
|
||||
|
||||
### Case 4: Missing Sound Bible — Skill notes the gap and proceeds without it
|
||||
|
||||
**Fixture:**
|
||||
- GDD for the target feature exists at `design/gdd/main-menu.md`
|
||||
- `design/gdd/sound-bible.md` does NOT exist
|
||||
- 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."
|
||||
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
|
||||
|
||||
**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
|
||||
- [ ] Verdict is still COMPLETE if all other steps succeed
|
||||
|
||||
---
|
||||
|
||||
### Case 5: Engine Not Configured — Engine specialist step skipped gracefully
|
||||
|
||||
**Fixture:**
|
||||
- Engine is NOT configured in `.claude/docs/technical-preferences.md` (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)
|
||||
|
||||
**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
|
||||
- [ ] 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)
|
||||
|
||||
---
|
||||
|
||||
## Protocol Compliance
|
||||
|
||||
- [ ] 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
|
||||
- [ ] 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
|
||||
- [ ] Next Steps handoff references `/dev-story` and `/asset-audit`
|
||||
|
||||
---
|
||||
|
||||
## Coverage Notes
|
||||
|
||||
- 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.
|
||||
- Step 4 (gameplay-programmer) happy-path behavior is validated implicitly by Case 1.
|
||||
Failure modes for this step follow the standard Error Recovery Protocol.
|
||||
- The accessibility-specialist's subtitle and caption requirements (beyond visual fallbacks)
|
||||
are validated implicitly by Case 1. Case 2 focuses on the more severe case where a
|
||||
critical gameplay event has no fallback at all.
|
||||
- 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.
|
||||
180
CCGS Skill Testing Framework/skills/team/team-combat.md
Normal file
180
CCGS Skill Testing Framework/skills/team/team-combat.md
Normal file
@@ -0,0 +1,180 @@
|
||||
# Skill Test Spec: /team-combat
|
||||
|
||||
## Skill Summary
|
||||
|
||||
Orchestrates the full combat team pipeline end-to-end for a single combat feature.
|
||||
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`,
|
||||
`/balance-check`, and `/team-polish`.
|
||||
|
||||
---
|
||||
|
||||
## Static Assertions (Structural)
|
||||
|
||||
- [ ] 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
|
||||
- [ ] 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
|
||||
- [ ] 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`)
|
||||
- [ ] Team Composition lists all seven roles (game-designer, gameplay-programmer, ai-programmer, technical-artist, sound-designer, engine specialist, qa-tester)
|
||||
|
||||
---
|
||||
|
||||
## Test Cases
|
||||
|
||||
### Case 1: Happy Path — All agents succeed, full pipeline runs to completion
|
||||
|
||||
**Fixture:**
|
||||
- `design/gdd/game-concept.md` exists and is populated
|
||||
- Engine is configured in `.claude/docs/technical-preferences.md` (Engine Specialists section filled)
|
||||
- No existing GDD for the requested combat feature
|
||||
|
||||
**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`
|
||||
|
||||
**Assertions:**
|
||||
- [ ] `AskUserQuestion` called at each phase gate (at minimum before Phase 3 and before Phase 5)
|
||||
- [ ] 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)
|
||||
- [ ] Verdict COMPLETE present in final report
|
||||
- [ ] Next steps include `/code-review`, `/balance-check`, `/team-polish`
|
||||
- [ ] Design doc covers all 8 required GDD sections
|
||||
|
||||
---
|
||||
|
||||
### Case 2: Blocked Agent — One subagent returns BLOCKED mid-pipeline
|
||||
|
||||
**Fixture:**
|
||||
- `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)
|
||||
|
||||
**Input:** `/team-combat parry and riposte system`
|
||||
|
||||
**Expected behavior:**
|
||||
1. Phase 1 — design doc found; game-designer confirms it is valid; phase approved
|
||||
2. Phase 2 — gameplay-programmer completes architecture sketch; ai-programmer returns BLOCKED: "ADR for AI behavior system is Proposed — cannot implement until ADR is Accepted"
|
||||
3. Error Recovery Protocol triggered: "ai-programmer: BLOCKED — AI behavior ADR is Proposed"
|
||||
4. `AskUserQuestion` presented with options: (a) Skip ai-programmer and note the gap; (b) Retry with narrower scope; (c) Stop here and run `/architecture-decision` first
|
||||
5. If user chooses (a): Phase 3 proceeds with gameplay-programmer, technical-artist, sound-designer only; ai-programmer gap noted in partial report
|
||||
6. Final report produced: partial implementation documented, ai-programmer section marked BLOCKED, overall verdict: BLOCKED
|
||||
|
||||
**Assertions:**
|
||||
- [ ] BLOCKED surface message appears before any dependent phase continues
|
||||
- [ ] `AskUserQuestion` offers at minimum three options: skip / retry / stop
|
||||
- [ ] Partial report produced — completed agents' work is not discarded
|
||||
- [ ] Overall verdict is BLOCKED (not COMPLETE) when any agent is unresolved
|
||||
- [ ] Blocked reason references the ADR and suggests `/architecture-decision`
|
||||
- [ ] Orchestrator does not silently proceed past the blocked dependency
|
||||
|
||||
---
|
||||
|
||||
### Case 3: No Argument — Clear usage guidance shown
|
||||
|
||||
**Fixture:**
|
||||
- Any project state
|
||||
|
||||
**Input:** `/team-combat` (no argument)
|
||||
|
||||
**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]`
|
||||
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
|
||||
- [ ] 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)
|
||||
|
||||
---
|
||||
|
||||
### 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
|
||||
- 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
|
||||
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)
|
||||
- [ ] 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
|
||||
|
||||
**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`
|
||||
|
||||
**Input:** `/team-combat parry and riposte system`
|
||||
|
||||
**Expected behavior:**
|
||||
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
|
||||
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
|
||||
|
||||
**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
|
||||
|
||||
---
|
||||
|
||||
## 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
|
||||
- [ ] Error Recovery Protocol followed: surface → assess → offer options → partial report
|
||||
- [ ] 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`
|
||||
|
||||
---
|
||||
|
||||
## Coverage Notes
|
||||
|
||||
- The NEEDS WORK verdict path (qa-tester finds failures in Phase 5) is not separately tested
|
||||
here; it follows the same error recovery and partial report protocol as Case 2.
|
||||
- "Retry with narrower scope" error recovery option is listed in assertions but its full
|
||||
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.
|
||||
209
CCGS Skill Testing Framework/skills/team/team-level.md
Normal file
209
CCGS Skill Testing Framework/skills/team/team-level.md
Normal file
@@ -0,0 +1,209 @@
|
||||
# Skill Test Spec: /team-level
|
||||
|
||||
## Skill Summary
|
||||
|
||||
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`.
|
||||
|
||||
---
|
||||
|
||||
## Static Assertions (Structural)
|
||||
|
||||
- [ ] 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
|
||||
- [ ] 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)
|
||||
- [ ] accessibility-specialist output includes severity ratings (BLOCKING / RECOMMENDED / NICE TO HAVE)
|
||||
- [ ] Final level design document saved to `design/levels/[level-name].md`
|
||||
|
||||
---
|
||||
|
||||
## Test Cases
|
||||
|
||||
### Case 1: Happy Path — All team members produce outputs, document compiled and saved
|
||||
|
||||
**Fixture:**
|
||||
- `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
|
||||
|
||||
**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`
|
||||
|
||||
**Assertions:**
|
||||
- [ ] 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)
|
||||
- [ ] `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
|
||||
- [ ] 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`
|
||||
- [ ] Summary report includes: area overview, encounter count, estimated asset list, narrative beats
|
||||
|
||||
---
|
||||
|
||||
### Case 2: Blocked Agent (world-builder) — Partial report produced with gap noted
|
||||
|
||||
**Fixture:**
|
||||
- `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"
|
||||
|
||||
**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
|
||||
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
|
||||
- (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
|
||||
|
||||
**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
|
||||
- [ ] Overall verdict is BLOCKED (not COMPLETE) when world-builder remains unresolved
|
||||
- [ ] Skill does NOT silently fabricate lore content to fill the gap
|
||||
|
||||
---
|
||||
|
||||
### Case 3: No Argument — Usage guidance shown
|
||||
|
||||
**Fixture:**
|
||||
- Any project state
|
||||
|
||||
**Input:** `/team-level` (no argument)
|
||||
|
||||
**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`
|
||||
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
|
||||
- [ ] 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)
|
||||
|
||||
---
|
||||
|
||||
### Case 4: Accessibility Review Gate — Blocking concern surfaces before sign-off
|
||||
|
||||
**Fixture:**
|
||||
- Steps 1–3 complete successfully
|
||||
- `design/accessibility-requirements.md` committed tier: Enhanced
|
||||
- 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."
|
||||
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
|
||||
|
||||
**Assertions:**
|
||||
- [ ] BLOCKING accessibility concern is not treated as advisory — it is surfaced as a blocker
|
||||
- [ ] `AskUserQuestion` presents the specific concern text (not just "accessibility issue found")
|
||||
- [ ] Step 5 (qa-tester) does NOT begin without user acknowledging the BLOCKING concern
|
||||
- [ ] Revision path offered: level-designer + art-director can be sent back before proceeding
|
||||
- [ ] Final report includes the accessibility concern and its resolution status
|
||||
- [ ] art-director's completed output is NOT discarded when accessibility-specialist blocks
|
||||
|
||||
---
|
||||
|
||||
### Case 5: Circular Level Reference — Adjacent area dependency flagged
|
||||
|
||||
**Fixture:**
|
||||
- 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
|
||||
|
||||
**Input:** `/team-level forest dungeon`
|
||||
|
||||
**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
|
||||
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
|
||||
7. Final report includes open cross-level dependencies section
|
||||
|
||||
**Assertions:**
|
||||
- [ ] Skill detects the missing adjacent area by checking `design/levels/` — does not assume it will be created later
|
||||
- [ ] Skill does NOT fabricate crystal caves content (lore, layout, connections) to resolve the reference
|
||||
- [ ] `AskUserQuestion` offers a "design crystal caves first" option referencing `/team-level`
|
||||
- [ ] If user proceeds with placeholder, level doc explicitly marks the west exit as UNRESOLVED
|
||||
- [ ] Summary report includes an open cross-level dependencies section listing unresolved references
|
||||
- [ ] Circular or forward references do not cause the skill to loop or crash
|
||||
|
||||
---
|
||||
|
||||
## 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
|
||||
- [ ] Error Recovery Protocol followed: surface → assess → offer options → partial report
|
||||
- [ ] Step 4 agents (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
|
||||
- [ ] Verdict is one of COMPLETE / BLOCKED
|
||||
- [ ] Next steps present at end: `/design-review`, `/dev-story`, `/qa-plan`
|
||||
|
||||
---
|
||||
|
||||
## 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.
|
||||
- systems-designer (Step 3) block scenarios are not separately tested; the same Error Recovery
|
||||
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.
|
||||
178
CCGS Skill Testing Framework/skills/team/team-live-ops.md
Normal file
178
CCGS Skill Testing Framework/skills/team/team-live-ops.md
Normal file
@@ -0,0 +1,178 @@
|
||||
# Skill Test Spec: /team-live-ops
|
||||
|
||||
## Skill Summary
|
||||
|
||||
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.
|
||||
|
||||
---
|
||||
|
||||
## Static Assertions (Structural)
|
||||
|
||||
- [ ] 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 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
|
||||
- [ ] States explicitly that Phases 3 and 4 can run simultaneously (parallel spawning)
|
||||
- [ ] Error recovery section present (or implied through BLOCKED handling)
|
||||
- [ ] Output documents section specifies paths under `design/live-ops/seasons/`
|
||||
|
||||
---
|
||||
|
||||
## Test Cases
|
||||
|
||||
### Case 1: Happy Path — All 7 phases complete, season plan produced
|
||||
|
||||
**Fixture:**
|
||||
- `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
|
||||
- No existing season documents for the new season name being planned
|
||||
|
||||
**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
|
||||
|
||||
**Assertions:**
|
||||
- [ ] All 7 phases execute in order; Phase 3 and 4 are issued as parallel Task 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
|
||||
- [ ] Next steps reference `/design-review`, `/sprint-plan`, and `/team-release`
|
||||
|
||||
---
|
||||
|
||||
### Case 2: Ethics Violation Found — Reward element violates ethics policy
|
||||
|
||||
**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
|
||||
|
||||
**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."
|
||||
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
|
||||
|
||||
**Assertions:**
|
||||
- [ ] Phase 7 ethics review section explicitly names the violating element and the policy rule it breaks
|
||||
- [ ] Skill does not auto-approve the season plan when an ethics violation is present
|
||||
- [ ] 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
|
||||
|
||||
---
|
||||
|
||||
### Case 3: No Argument — Usage guidance shown
|
||||
|
||||
**Fixture:**
|
||||
- Any project state
|
||||
|
||||
**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."
|
||||
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
|
||||
- [ ] No files are read or written
|
||||
|
||||
---
|
||||
|
||||
### Case 4: Parallel Phase Validation — Phases 3 and 4 run simultaneously
|
||||
|
||||
**Fixture:**
|
||||
- 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
|
||||
|
||||
**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
|
||||
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
|
||||
- [ ] 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
|
||||
- [ ] Skill documentation explicitly states "Phases 3 and 4 can run simultaneously"
|
||||
|
||||
---
|
||||
|
||||
### Case 5: Missing Ethics Policy — `design/live-ops/ethics-policy.md` does not exist
|
||||
|
||||
**Fixture:**
|
||||
- `design/live-ops/economy-rules.md` exists
|
||||
- `design/live-ops/ethics-policy.md` does NOT exist
|
||||
- All other fixtures are present
|
||||
|
||||
**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
|
||||
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
|
||||
5. Next steps include a recommendation to create the ethics policy document
|
||||
|
||||
**Assertions:**
|
||||
- [ ] Skill does NOT error out when the ethics policy file is missing
|
||||
- [ ] Skill does NOT fabricate ethics policy rules in the absence of the file
|
||||
- [ ] Phase 7 summary explicitly notes that ethics review was skipped and why
|
||||
- [ ] Verdict: COMPLETE is still reachable despite the missing file
|
||||
- [ ] Gap flag appears in the season design output document (not just in conversation)
|
||||
- [ ] Next steps recommend creating `design/live-ops/ethics-policy.md`
|
||||
|
||||
---
|
||||
|
||||
## 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
|
||||
- [ ] 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`
|
||||
|
||||
---
|
||||
|
||||
## 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.
|
||||
- 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.
|
||||
209
CCGS Skill Testing Framework/skills/team/team-narrative.md
Normal file
209
CCGS Skill Testing Framework/skills/team/team-narrative.md
Normal file
@@ -0,0 +1,209 @@
|
||||
# Skill Test Spec: /team-narrative
|
||||
|
||||
## 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.
|
||||
|
||||
---
|
||||
|
||||
## Static Assertions (Structural)
|
||||
|
||||
- [ ] Has required frontmatter fields: `name`, `description`, `argument-hint`, `user-invocable`, `allowed-tools`
|
||||
- [ ] 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
|
||||
- [ ] 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
|
||||
- [ ] Phase 5 explicitly spawns writer, localization-lead, and world-builder in parallel
|
||||
|
||||
---
|
||||
|
||||
## Test Cases
|
||||
|
||||
### Case 1: Happy Path — All five phases complete, narrative doc delivered
|
||||
|
||||
**Fixture:**
|
||||
- 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/`)
|
||||
- No lore contradictions exist between existing entries and the new content
|
||||
|
||||
**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
|
||||
|
||||
**Assertions:**
|
||||
- [ ] 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)
|
||||
- [ ] level-designer is not launched until Phase 2 `AskUserQuestion` is approved
|
||||
- [ ] narrative-director is re-spawned in Phase 4 for consistency review
|
||||
- [ ] Phase 5 spawns all three agents (writer, localization-lead, world-builder) simultaneously
|
||||
- [ ] 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
|
||||
- [ ] Verdict is COMPLETE after delivery
|
||||
|
||||
---
|
||||
|
||||
### Case 2: Lore Contradiction Found — world-builder finds conflict before writer proceeds
|
||||
|
||||
**Fixture:**
|
||||
- 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
|
||||
|
||||
**Input:** `/team-narrative ironveil faction introduction cutscene`
|
||||
|
||||
**Expected behavior:**
|
||||
1. Phases 1–2 begin normally
|
||||
2. Phase 2 world-builder detects a factual contradiction between the narrative brief and existing lore: founding date conflict
|
||||
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)
|
||||
- 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
|
||||
8. Orchestrator does NOT proceed to Phase 3 until the contradiction is resolved or user explicitly chooses to skip
|
||||
|
||||
**Assertions:**
|
||||
- [ ] Contradiction is surfaced before Phase 3 begins
|
||||
- [ ] 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
|
||||
- [ ] Verdict is BLOCKED (not COMPLETE) if the user stops to resolve the contradiction
|
||||
|
||||
---
|
||||
|
||||
### Case 3: No Argument — Usage guidance shown
|
||||
|
||||
**Fixture:**
|
||||
- Any project state
|
||||
|
||||
**Input:** `/team-narrative` (no argument)
|
||||
|
||||
**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`)"
|
||||
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
|
||||
- [ ] 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
|
||||
|
||||
**Fixture:**
|
||||
- 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
|
||||
|
||||
**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
|
||||
- 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
|
||||
|
||||
**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
|
||||
- [ ] Skill does NOT automatically rewrite the offending line without user approval
|
||||
|
||||
---
|
||||
|
||||
### Case 5: Writer Blocked — Missing character voice profiles
|
||||
|
||||
**Fixture:**
|
||||
- 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
|
||||
|
||||
**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
|
||||
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
|
||||
- Stop here and create voice profiles before proceeding
|
||||
7. Orchestrator does NOT proceed to Phase 3 (level-designer) without writer output
|
||||
|
||||
**Assertions:**
|
||||
- [ ] Writer block is surfaced before Phase 3 begins
|
||||
- [ ] world-builder's completed lore output is preserved in the partial report
|
||||
- [ ] Missing prerequisite (voice profiles) is named specifically (character names and expected file path)
|
||||
- [ ] `AskUserQuestion` offers at least one option to resolve the missing prerequisite
|
||||
- [ ] Orchestrator does not fabricate voice profiles or invent character voices
|
||||
- [ ] Phase 3 is not launched while writer is BLOCKED without explicit user authorization
|
||||
|
||||
---
|
||||
|
||||
## 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
|
||||
- [ ] 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
|
||||
- [ ] Next Steps handoff references `/design-review`, `/localize extract`, and `/dev-story`
|
||||
|
||||
---
|
||||
|
||||
## Coverage Notes
|
||||
|
||||
- Phase 3 (level-designer) and Phase 4 (narrative-director review) happy-path behavior are
|
||||
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.
|
||||
- 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.
|
||||
218
CCGS Skill Testing Framework/skills/team/team-polish.md
Normal file
218
CCGS Skill Testing Framework/skills/team/team-polish.md
Normal file
@@ -0,0 +1,218 @@
|
||||
# Skill Test Spec: /team-polish
|
||||
|
||||
## 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
|
||||
(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.
|
||||
|
||||
---
|
||||
|
||||
## Static Assertions (Structural)
|
||||
|
||||
- [ ] 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 "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
|
||||
- [ ] 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
|
||||
- [ ] Phase 3 (visual polish) and Phase 4 (audio polish) are explicitly run in parallel with Phase 2
|
||||
- [ ] 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
|
||||
|
||||
---
|
||||
|
||||
## Test Cases
|
||||
|
||||
### Case 1: Happy Path — Full pipeline completes, READY FOR RELEASE verdict
|
||||
|
||||
**Fixture:**
|
||||
- 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)
|
||||
- No frame budget violations exist before polishing begins
|
||||
- No audio events are missing; VFX assets are complete
|
||||
- No regressions are introduced by polish changes
|
||||
|
||||
**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
|
||||
|
||||
**Assertions:**
|
||||
- [ ] 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)
|
||||
- [ ] engine-programmer is NOT spawned when Phase 1 finds no engine-level root causes
|
||||
- [ ] qa-tester (Phase 5) is not launched until the parallel phases complete and user approves
|
||||
- [ ] 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
|
||||
- [ ] No files are written by the orchestrator directly
|
||||
- [ ] Verdict is READY FOR RELEASE
|
||||
|
||||
---
|
||||
|
||||
### Case 2: Performance Blocker — Frame budget violation cannot be fully resolved
|
||||
|
||||
**Fixture:**
|
||||
- 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 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"
|
||||
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."
|
||||
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"
|
||||
9. Next Steps: schedule the remaining issue in `/sprint-plan update`; re-run `/team-polish` after fix
|
||||
|
||||
**Assertions:**
|
||||
- [ ] Frame budget violation is flagged in Phase 1 with specific numbers (actual vs. budget)
|
||||
- [ ] Phase 2 reports the post-optimization metric explicitly (9ms achieved, 3ms still over)
|
||||
- [ ] Verdict is NEEDS MORE WORK (not READY FOR RELEASE) when a budget violation remains
|
||||
- [ ] The specific unresolved issue is listed by name with the remaining gap quantified
|
||||
- [ ] Next Steps references `/sprint-plan update` for scheduling the remaining fix
|
||||
- [ ] Phases 3 and 4 still run (polish work is not abandoned due to a Phase 2 partial resolution)
|
||||
- [ ] Phase 5 qa-tester still runs (regression testing is independent of the performance outcome)
|
||||
|
||||
---
|
||||
|
||||
### Case 3: No Argument — Usage guidance shown
|
||||
|
||||
**Fixture:**
|
||||
- Any project state
|
||||
|
||||
**Input:** `/team-polish` (no argument)
|
||||
|
||||
**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`)"
|
||||
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
|
||||
- [ ] Skill does NOT attempt to guess a feature from project files
|
||||
- [ ] No `AskUserQuestion` is used — output is direct guidance
|
||||
|
||||
---
|
||||
|
||||
### Case 4: Engine-Level Bottleneck — engine-programmer spawned conditionally in Phase 2
|
||||
|
||||
**Fixture:**
|
||||
- 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
|
||||
|
||||
**Input:** `/team-polish open-world`
|
||||
|
||||
**Expected behavior:**
|
||||
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
|
||||
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)
|
||||
- [ ] 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
|
||||
- [ ] Verdict correctly reflects whether all metrics including the engine fix now meet budgets
|
||||
|
||||
---
|
||||
|
||||
### Case 5: Regression Found — Polish change broke an existing feature
|
||||
|
||||
**Fixture:**
|
||||
- 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
|
||||
|
||||
**Input:** `/team-polish inventory-ui` (Phase 5 scenario)
|
||||
|
||||
**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)
|
||||
|
||||
**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
|
||||
- [ ] 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
|
||||
|
||||
---
|
||||
|
||||
## Protocol Compliance
|
||||
|
||||
- [ ] 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
|
||||
- [ ] 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
|
||||
- [ ] 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)
|
||||
|
||||
---
|
||||
|
||||
## Coverage Notes
|
||||
|
||||
- The tools-programmer optional agent (for content pipeline tool verification) 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.
|
||||
- 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.
|
||||
- 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.
|
||||
204
CCGS Skill Testing Framework/skills/team/team-qa.md
Normal file
204
CCGS Skill Testing Framework/skills/team/team-qa.md
Normal file
@@ -0,0 +1,204 @@
|
||||
# Skill Test Spec: /team-qa
|
||||
|
||||
## 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.
|
||||
|
||||
---
|
||||
|
||||
## Static Assertions (Structural)
|
||||
|
||||
- [ ] Has required frontmatter fields: `name`, `description`, `argument-hint`, `user-invocable`, `allowed-tools`
|
||||
- [ ] Has ≥2 phase headings
|
||||
- [ ] 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
|
||||
- [ ] 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
|
||||
|
||||
---
|
||||
|
||||
## Test Cases
|
||||
|
||||
### 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
|
||||
- All stories have acceptance criteria populated
|
||||
- `tests/smoke/` contains a smoke test list; all items are verifiable
|
||||
- No existing bugs in `production/qa/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
|
||||
8. Verdict: COMPLETE — QA cycle finished
|
||||
|
||||
**Assertions:**
|
||||
- [ ] Phase 1 correctly counts and reports 4 stories with current stage
|
||||
- [ ] Strategy table in Phase 2 classifies all 4 stories with correct types
|
||||
- [ ] 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
|
||||
- [ ] 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
|
||||
- [ ] Next step: "Run `/gate-check` to validate advancement."
|
||||
|
||||
---
|
||||
|
||||
### Case 2: Smoke Check Fail — QA cycle stops at Phase 4
|
||||
|
||||
**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)
|
||||
|
||||
**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
|
||||
|
||||
**Assertions:**
|
||||
- [ ] Smoke check FAIL causes the pipeline to halt at Phase 4 — Phases 5, 6, 7 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)
|
||||
|
||||
---
|
||||
|
||||
### 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
|
||||
- The Visual/Feel story's animation timing is visibly wrong (acceptance criterion not met)
|
||||
- `production/qa/bugs/` directory exists (empty or with existing bugs)
|
||||
|
||||
**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)
|
||||
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
|
||||
- [ ] 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)
|
||||
|
||||
---
|
||||
|
||||
### Case 4: No Argument — Skill infers active sprint or asks user
|
||||
|
||||
**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
|
||||
|
||||
**Fixture (variant B — state files absent):**
|
||||
- `production/session-state/active.md` does NOT exist
|
||||
- `production/sprint-status.yaml` does NOT exist
|
||||
|
||||
**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."
|
||||
|
||||
**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
|
||||
|
||||
**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)
|
||||
- [ ] Skill does NOT error out when state files are missing — it falls back to asking (variant B)
|
||||
|
||||
---
|
||||
|
||||
### 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
|
||||
- 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)
|
||||
|
||||
**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."
|
||||
|
||||
**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
|
||||
- [ ] 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
|
||||
- [ ] 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
|
||||
|
||||
---
|
||||
|
||||
## 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
|
||||
- [ ] 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
|
||||
|
||||
---
|
||||
|
||||
## 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.
|
||||
- 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.
|
||||
215
CCGS Skill Testing Framework/skills/team/team-release.md
Normal file
215
CCGS Skill Testing Framework/skills/team/team-release.md
Normal file
@@ -0,0 +1,215 @@
|
||||
# Skill Test Spec: /team-release
|
||||
|
||||
## Skill Summary
|
||||
|
||||
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.
|
||||
|
||||
---
|
||||
|
||||
## Static Assertions (Structural)
|
||||
|
||||
- [ ] 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`
|
||||
- [ ] Uses `AskUserQuestion` at phase transitions requiring user approval before proceeding
|
||||
- [ ] 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
|
||||
|
||||
---
|
||||
|
||||
## Test Cases
|
||||
|
||||
### Case 1: Happy Path (Single-Player) — All phases complete, version deployed
|
||||
|
||||
**Fixture:**
|
||||
- `production/stage.txt` exists and contains a Production-or-later stage
|
||||
- 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
|
||||
|
||||
**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
|
||||
|
||||
**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
|
||||
- [ ] `/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
|
||||
- [ ] Phase 7 monitoring plan includes a 48-hour post-release monitoring commitment
|
||||
- [ ] Next steps recommend updating `production/stage.txt` to `Live` after successful deployment
|
||||
- [ ] Verdict: COMPLETE appears in the final output
|
||||
|
||||
---
|
||||
|
||||
### Case 2: Go/No-Go: NO — S1 bug found in Phase 3, deployment skipped
|
||||
|
||||
**Fixture:**
|
||||
- Release candidate branch exists for v0.9.0
|
||||
- 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
|
||||
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
|
||||
|
||||
**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
|
||||
- [ ] 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
|
||||
|
||||
---
|
||||
|
||||
### Case 3: Security Audit for Online Game — security-engineer is spawned in Phase 3
|
||||
|
||||
**Fixture:**
|
||||
- Game has multiplayer features and 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
|
||||
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
|
||||
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
|
||||
- [ ] 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 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
|
||||
|
||||
**Fixture:**
|
||||
- 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
|
||||
|
||||
**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
|
||||
|
||||
**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
|
||||
|
||||
---
|
||||
|
||||
### Case 5: No Argument — Skill infers version or asks
|
||||
|
||||
**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
|
||||
|
||||
**Fixture (variant B — no discoverable version):**
|
||||
- `production/milestones/` does not exist
|
||||
- `production/session-state/active.md` does not reference a version
|
||||
- No git tags are present from which to infer a version
|
||||
|
||||
**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/`
|
||||
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?"
|
||||
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
|
||||
2. Uses AskUserQuestion: "What version number should be released? (e.g., v1.0.0)"
|
||||
3. Waits for user input before proceeding
|
||||
|
||||
**Assertions:**
|
||||
- [ ] Skill does NOT default to a hardcoded version string when no argument is provided
|
||||
- [ ] Skill reads `production/session-state/active.md` and milestone files before asking (variant A)
|
||||
- [ ] Inferred version is confirmed with the user via AskUserQuestion before proceeding (variant A)
|
||||
- [ ] When no version is discoverable, AskUserQuestion is used — skill does not guess (variant B)
|
||||
- [ ] Skill does NOT error out when milestone files are absent — it falls back to asking (variant B)
|
||||
|
||||
---
|
||||
|
||||
## 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
|
||||
- [ ] 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`
|
||||
|
||||
---
|
||||
|
||||
## 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.
|
||||
201
CCGS Skill Testing Framework/skills/team/team-ui.md
Normal file
201
CCGS Skill Testing Framework/skills/team/team-ui.md
Normal file
@@ -0,0 +1,201 @@
|
||||
# Skill Test Spec: /team-ui
|
||||
|
||||
## Skill Summary
|
||||
|
||||
Orchestrates the UI team through the full UX pipeline for a single UI feature.
|
||||
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`.
|
||||
|
||||
---
|
||||
|
||||
## Static Assertions (Structural)
|
||||
|
||||
- [ ] 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
|
||||
- [ ] 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
|
||||
- [ ] 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
|
||||
- [ ] Team Composition lists all five roles (ux-designer, ui-programmer, art-director, engine UI specialist, accessibility-specialist)
|
||||
- [ ] 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
|
||||
|
||||
---
|
||||
|
||||
## Test Cases
|
||||
|
||||
### Case 1: Happy Path — Full pipeline from UX spec through polish succeeds
|
||||
|
||||
**Fixture:**
|
||||
- `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`
|
||||
|
||||
**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
|
||||
|
||||
**Assertions:**
|
||||
- [ ] Phase 1a reads all five sources 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
|
||||
- [ ] Phase 4 agents launched simultaneously (ux-designer, art-director, accessibility-specialist)
|
||||
- [ ] 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`
|
||||
|
||||
---
|
||||
|
||||
### Case 2: UX Review Gate — Spec fails review; skill halts before implementation
|
||||
|
||||
**Fixture:**
|
||||
- `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)
|
||||
|
||||
**Input:** `/team-ui inventory screen`
|
||||
|
||||
**Expected behavior:**
|
||||
1. Phase 1a + 1b complete — UX spec produced
|
||||
2. Phase 1c — `/ux-review design/ux/inventory-screen.md` returns NEEDS REVISION
|
||||
3. Skill does NOT advance to Phase 2
|
||||
4. `AskUserQuestion` presented with the specific flagged concerns and options:
|
||||
- (a) Return to ux-designer to address the issues and re-review
|
||||
- (b) Accept the risk and proceed to Phase 2 anyway (conscious decision)
|
||||
5. If user chooses (a): ux-designer revises spec, `/ux-review` re-run; loop continues until APPROVED or user overrides
|
||||
6. If user chooses (b): skill proceeds with an explicit NEEDS REVISION note in the final report
|
||||
7. Skill does NOT silently proceed past the gate
|
||||
|
||||
**Assertions:**
|
||||
- [ ] 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
|
||||
- [ ] Revision-and-re-review loop is offered (not just a one-shot failure)
|
||||
- [ ] Skill does NOT discard the produced UX spec on review failure
|
||||
|
||||
---
|
||||
|
||||
### Case 3: No Argument — Usage guidance shown
|
||||
|
||||
**Fixture:**
|
||||
- Any project state
|
||||
|
||||
**Input:** `/team-ui` (no argument)
|
||||
|
||||
**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]`
|
||||
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
|
||||
- [ ] 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)
|
||||
|
||||
---
|
||||
|
||||
### Case 4: Accessibility Parallel Review — Phase 4 runs three streams simultaneously
|
||||
|
||||
**Fixture:**
|
||||
- `design/ux/inventory-screen.md` exists (APPROVED)
|
||||
- Visual design spec complete
|
||||
- Implementation complete
|
||||
- `design/accessibility-requirements.md` committed tier: Enhanced
|
||||
|
||||
**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
|
||||
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
|
||||
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)
|
||||
- [ ] 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)
|
||||
- [ ] `AskUserQuestion` shows all three review streams' results together before Phase 5 approval
|
||||
- [ ] No Phase 4 agent's output is used as input for another Phase 4 agent
|
||||
|
||||
---
|
||||
|
||||
### Case 5: Missing Interaction Pattern Library — Skill notes the gap rather than inventing patterns
|
||||
|
||||
**Fixture:**
|
||||
- `design/ux/interaction-patterns.md` does NOT exist
|
||||
- All other required files present
|
||||
|
||||
**Input:** `/team-ui settings menu`
|
||||
|
||||
**Expected behavior:**
|
||||
1. Phase 1a — orchestrator attempts to read `design/ux/interaction-patterns.md`; file not found
|
||||
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
|
||||
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)
|
||||
|
||||
**Assertions:**
|
||||
- [ ] Skill does NOT silently ignore the missing pattern library
|
||||
- [ ] Skill does NOT invent patterns by guessing from the feature name or GDD alone
|
||||
- [ ] `AskUserQuestion` offers a "create pattern library first" option (referencing `/ux-design patterns`)
|
||||
- [ ] If user proceeds without the library, ui-programmer is told to treat all patterns as new
|
||||
- [ ] Final report documents pattern library status (created / absent / updated)
|
||||
- [ ] Skill does NOT fail entirely — the gap is noted and user is given a choice
|
||||
|
||||
---
|
||||
|
||||
## 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
|
||||
- [ ] 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
|
||||
- [ ] Partial report always produced even when agents are BLOCKED
|
||||
- [ ] Verdict is one of COMPLETE / BLOCKED
|
||||
- [ ] Next steps present at end: `/ux-review`, `/code-review`, `/team-polish`
|
||||
|
||||
---
|
||||
|
||||
## Coverage Notes
|
||||
|
||||
- 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
|
||||
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.
|
||||
Reference in New Issue
Block a user