添加 claude code game studios 到项目
This commit is contained in:
panw
@@ -0,0 +1,84 @@
|
||||
# Agent Test Spec: art-director
|
||||
|
||||
## Agent Summary
|
||||
**Domain owned:** Visual identity, art bible authorship and enforcement, asset quality standards, UI/UX visual design, visual phase gate, concept art evaluation.
|
||||
**Does NOT own:** UX interaction flows and information architecture (ux-designer's domain), audio direction (audio-director), code implementation.
|
||||
**Model tier:** Sonnet (note: despite the "director" title, art-director is assigned Sonnet per coordination-rules.md — it handles individual system analysis, not multi-document phase gate synthesis at the Opus level).
|
||||
**Gate IDs handled:** AD-CONCEPT-VISUAL, AD-ART-BIBLE, AD-PHASE-GATE.
|
||||
|
||||
---
|
||||
|
||||
## Static Assertions (Structural)
|
||||
|
||||
Verified by reading the agent's `.claude/agents/art-director.md` frontmatter:
|
||||
|
||||
- [ ] `description:` field is present and domain-specific (references visual identity, art bible, asset standards — not generic)
|
||||
- [ ] `allowed-tools:` list is read-focused; image review capability if supported; no Bash unless asset pipeline checks are justified
|
||||
- [ ] Model tier is `claude-sonnet-4-6` (NOT Opus — coordination-rules.md assigns Sonnet to art-director)
|
||||
- [ ] Agent definition does not claim authority over UX interaction flows or audio direction
|
||||
|
||||
---
|
||||
|
||||
## Test Cases
|
||||
|
||||
### Case 1: In-domain request — appropriate output format
|
||||
**Scenario:** The art bible's color palette section is submitted for review. The section defines a desaturated earth-tone primary palette with high-contrast accent colors tied to the game pillar "beauty in decay." The palette is internally consistent and references the pillar vocabulary. Request is tagged AD-ART-BIBLE.
|
||||
**Expected:** Returns `AD-ART-BIBLE: APPROVE` with rationale confirming the palette's internal consistency and its alignment with the stated pillar.
|
||||
**Assertions:**
|
||||
- [ ] Verdict is exactly one of APPROVE / CONCERNS / REJECT
|
||||
- [ ] Verdict token is formatted as `AD-ART-BIBLE: APPROVE`
|
||||
- [ ] Rationale references the specific palette characteristics and pillar alignment — not generic art advice
|
||||
- [ ] Output stays within visual domain — does not comment on UX interaction patterns or audio mood
|
||||
|
||||
### Case 2: Out-of-domain request — redirects or escalates
|
||||
**Scenario:** Sound designer asks art-director to specify how ambient audio should layer and duck when the player enters a combat zone.
|
||||
**Expected:** Agent declines to define audio behavior and redirects to audio-director.
|
||||
**Assertions:**
|
||||
- [ ] Does not make any binding decision about audio layering or ducking behavior
|
||||
- [ ] Explicitly names `audio-director` as the correct handler
|
||||
- [ ] May note if the audio has visual mood implications (e.g., "the audio should match the visual tension of the zone"), but defers all audio specification to audio-director
|
||||
|
||||
### Case 3: Gate verdict — correct vocabulary
|
||||
**Scenario:** Concept art for the protagonist is submitted. The art uses a vivid, saturated color palette (primary: #FF4500, #00BFFF) that directly contradicts the established art bible's "desaturated earth-tones" palette specification. Request is tagged AD-CONCEPT-VISUAL.
|
||||
**Expected:** Returns `AD-CONCEPT-VISUAL: CONCERNS` with specific citation of the palette discrepancy, referencing the art bible's stated palette values versus the submitted concept's palette.
|
||||
**Assertions:**
|
||||
- [ ] Verdict is exactly one of APPROVE / CONCERNS / REJECT — not freeform text
|
||||
- [ ] Verdict token is formatted as `AD-CONCEPT-VISUAL: CONCERNS`
|
||||
- [ ] Rationale specifically identifies the palette conflict — not a generic "doesn't match style" comment
|
||||
- [ ] References the art bible as the authoritative source for the correct palette
|
||||
|
||||
### Case 4: Conflict escalation — correct parent
|
||||
**Scenario:** ux-designer proposes using high-contrast, brightly colored icons for the HUD to improve readability. art-director believes this violates the art bible's muted visual language and would undermine the visual identity.
|
||||
**Expected:** art-director states the visual identity concern and references the art bible, acknowledges ux-designer's readability goal as legitimate, and escalates to creative-director to arbitrate the trade-off between visual coherence and usability.
|
||||
**Assertions:**
|
||||
- [ ] Escalates to `creative-director` (shared parent for creative domain conflicts)
|
||||
- [ ] Does not unilaterally override ux-designer's readability recommendation
|
||||
- [ ] Clearly frames the conflict as a trade-off between two legitimate goals
|
||||
- [ ] References the specific art bible rule being violated
|
||||
|
||||
### Case 5: Context pass — uses provided context
|
||||
**Scenario:** Agent receives a gate context block that includes the existing art bible with specific palette values (primary: #8B7355, #6B6B47; accent: #C8A96E) and style rules ("no pure white, no pure black; all shadows have warm undertones"). A new asset is submitted for review.
|
||||
**Expected:** Assessment references the specific hex values and style rules from the provided art bible, not generic color theory advice. Any concerns are tied to specific violations of the provided rules.
|
||||
**Assertions:**
|
||||
- [ ] References specific palette values from the provided art bible context
|
||||
- [ ] Applies the specific style rules (no pure white/black, warm shadow undertones) from the provided document
|
||||
- [ ] Does not generate generic art direction feedback disconnected from the supplied art bible
|
||||
- [ ] Verdict rationale is traceable to specific lines or rules in the provided context
|
||||
|
||||
---
|
||||
|
||||
## Protocol Compliance
|
||||
|
||||
- [ ] Returns verdicts using APPROVE / CONCERNS / REJECT vocabulary only
|
||||
- [ ] Stays within declared visual domain
|
||||
- [ ] Escalates UX-vs-visual conflicts to creative-director
|
||||
- [ ] Uses gate IDs in output (e.g., `AD-ART-BIBLE: APPROVE`) not inline prose verdicts
|
||||
- [ ] Does not make binding UX interaction, audio, or code implementation decisions
|
||||
|
||||
---
|
||||
|
||||
## Coverage Notes
|
||||
- AD-PHASE-GATE (full visual phase advancement) is not covered — deferred to integration with /gate-check skill.
|
||||
- Asset pipeline standards (file format, resolution, naming conventions) compliance checks are not covered here.
|
||||
- Shader visual output review is not covered — that interaction with the engine specialist is deferred.
|
||||
- UI component visual review (as distinct from UX flow review) could benefit from additional cases.
|
||||
@@ -0,0 +1,84 @@
|
||||
# Agent Test Spec: creative-director
|
||||
|
||||
## Agent Summary
|
||||
**Domain owned:** Creative vision, game pillars, GDD alignment, systems decomposition feedback, narrative direction, playtest feedback interpretation, phase gate (creative aspect).
|
||||
**Does NOT own:** Technical architecture or implementation details (delegates to technical-director), production scheduling (producer), visual art style execution (delegates to art-director).
|
||||
**Model tier:** Opus (multi-document synthesis, high-stakes phase gate verdicts).
|
||||
**Gate IDs handled:** CD-PILLARS, CD-GDD-ALIGN, CD-SYSTEMS, CD-NARRATIVE, CD-PLAYTEST, CD-PHASE-GATE.
|
||||
|
||||
---
|
||||
|
||||
## Static Assertions (Structural)
|
||||
|
||||
Verified by reading the agent's `.claude/agents/creative-director.md` frontmatter:
|
||||
|
||||
- [ ] `description:` field is present and domain-specific (references creative vision, pillars, GDD alignment — not generic)
|
||||
- [ ] `allowed-tools:` list is read-heavy; should not include Bash unless justified by a creative workflow need
|
||||
- [ ] Model tier is `claude-opus-4-6` per coordination-rules.md (directors with gate synthesis = Opus)
|
||||
- [ ] Agent definition does not claim authority over technical architecture or production scheduling
|
||||
|
||||
---
|
||||
|
||||
## Test Cases
|
||||
|
||||
### Case 1: In-domain request — appropriate output format
|
||||
**Scenario:** A game concept document is submitted for pillar review. The concept describes a narrative survival game built around three pillars: "emergent stories," "meaningful sacrifice," and "lived-in world." Request is tagged CD-PILLARS.
|
||||
**Expected:** Returns `CD-PILLARS: APPROVE` with rationale citing how each pillar is represented in the concept and any reinforcing or weakening signals found in the document.
|
||||
**Assertions:**
|
||||
- [ ] Verdict is exactly one of APPROVE / CONCERNS / REJECT
|
||||
- [ ] Verdict token is formatted as `CD-PILLARS: APPROVE` (gate ID prefix, colon, verdict keyword)
|
||||
- [ ] Rationale references the three specific pillars by name, not generic creative advice
|
||||
- [ ] Output stays within creative scope — does not comment on engine feasibility or sprint schedule
|
||||
|
||||
### Case 2: Out-of-domain request — redirects or escalates
|
||||
**Scenario:** Developer asks creative-director to review a proposed PostgreSQL schema for storing player save data.
|
||||
**Expected:** Agent declines to evaluate the schema and redirects to technical-director.
|
||||
**Assertions:**
|
||||
- [ ] Does not make any binding decision about the schema design
|
||||
- [ ] Explicitly names `technical-director` as the correct handler
|
||||
- [ ] May note whether the data model has creative implications (e.g., what player data is tracked), but defers structural decisions entirely
|
||||
|
||||
### Case 3: Gate verdict — correct vocabulary
|
||||
**Scenario:** A GDD for the "Crafting" system is submitted. Section 4 (Formulas) defines a resource decay formula that punishes exploration — contradicting the Player Fantasy section which calls for "freedom to roam without fear." Request is tagged CD-GDD-ALIGN.
|
||||
**Expected:** Returns `CD-GDD-ALIGN: CONCERNS` with specific citation of the contradiction between the formula behavior and the Player Fantasy statement.
|
||||
**Assertions:**
|
||||
- [ ] Verdict is exactly one of APPROVE / CONCERNS / REJECT — not freeform text
|
||||
- [ ] Verdict token is formatted as `CD-GDD-ALIGN: CONCERNS`
|
||||
- [ ] Rationale quotes or directly references GDD Section 4 (Formulas) and the Player Fantasy section
|
||||
- [ ] Does not prescribe a specific formula fix — that belongs to systems-designer
|
||||
|
||||
### Case 4: Conflict escalation — correct parent
|
||||
**Scenario:** technical-director raises a concern that the core loop mechanic (real-time branching conversations) is prohibitively expensive to implement and recommends cutting it. creative-director disagrees on creative grounds.
|
||||
**Expected:** creative-director acknowledges the technical constraint, does not override technical-director's feasibility assessment, but retains authority to define what the creative goal is. For the conflict itself, creative-director is the top-level creative escalation point and defers to technical-director on implementation feasibility while advocating for the design intent. The resolution path is for both to jointly present trade-off options to the user.
|
||||
**Assertions:**
|
||||
- [ ] Does not unilaterally override technical-director's feasibility concern
|
||||
- [ ] Clearly separates "what we want creatively" from "how it gets built"
|
||||
- [ ] Proposes presenting trade-offs to the user rather than resolving unilaterally
|
||||
- [ ] Does not claim to own implementation decisions
|
||||
|
||||
### Case 5: Context pass — uses provided context
|
||||
**Scenario:** Agent receives a gate context block that includes the game pillars document (`design/gdd/pillars.md`) and a new mechanic spec for review. The pillars document defines "player authorship," "consequence permanence," and "world responsiveness" as the three core pillars.
|
||||
**Expected:** Assessment uses the exact pillar vocabulary from the provided document, not generic creative heuristics. Any approval or concern is tied back to one or more of the three named pillars.
|
||||
**Assertions:**
|
||||
- [ ] Uses the exact pillar names from the provided context document
|
||||
- [ ] Does not generate generic creative feedback disconnected from the supplied pillars
|
||||
- [ ] References the specific pillar(s) most relevant to the mechanic under review
|
||||
- [ ] Does not reference pillars not present in the provided document
|
||||
|
||||
---
|
||||
|
||||
## Protocol Compliance
|
||||
|
||||
- [ ] Returns verdicts using APPROVE / CONCERNS / REJECT vocabulary only
|
||||
- [ ] Stays within declared creative domain
|
||||
- [ ] Escalates conflicts by presenting trade-offs to user rather than unilateral override
|
||||
- [ ] Uses gate IDs in output (e.g., `CD-PILLARS: APPROVE`) not inline prose verdicts
|
||||
- [ ] Does not make binding cross-domain decisions (technical, production, art execution)
|
||||
|
||||
---
|
||||
|
||||
## Coverage Notes
|
||||
- Multi-gate scenario (e.g., single submission triggering both CD-PILLARS and CD-GDD-ALIGN) is not covered here — deferred to integration tests.
|
||||
- CD-PHASE-GATE (full phase advancement) involves synthesizing multiple sub-gate results; this complex case is deferred.
|
||||
- Playtest report interpretation (CD-PLAYTEST) is not covered — a dedicated case should be added when the playtest-report skill produces structured output.
|
||||
- Interaction with art-director on visual-pillar alignment is not covered.
|
||||
84
CCGS Skill Testing Framework/agents/directors/producer.md
Normal file
84
CCGS Skill Testing Framework/agents/directors/producer.md
Normal file
@@ -0,0 +1,84 @@
|
||||
# Agent Test Spec: producer
|
||||
|
||||
## Agent Summary
|
||||
**Domain owned:** Scope management, sprint planning validation, milestone tracking, epic prioritization, production phase gate.
|
||||
**Does NOT own:** Game design decisions (creative-director / game-designer), technical architecture (technical-director), creative direction.
|
||||
**Model tier:** Opus (multi-document synthesis, high-stakes phase gate verdicts).
|
||||
**Gate IDs handled:** PR-SCOPE, PR-SPRINT, PR-MILESTONE, PR-EPIC, PR-PHASE-GATE.
|
||||
|
||||
---
|
||||
|
||||
## Static Assertions (Structural)
|
||||
|
||||
Verified by reading the agent's `.claude/agents/producer.md` frontmatter:
|
||||
|
||||
- [ ] `description:` field is present and domain-specific (references scope, sprint, milestone, production — not generic)
|
||||
- [ ] `allowed-tools:` list is primarily read-focused; Bash only if sprint/milestone files require parsing
|
||||
- [ ] Model tier is `claude-opus-4-6` per coordination-rules.md (directors with gate synthesis = Opus)
|
||||
- [ ] Agent definition does not claim authority over design decisions or technical architecture
|
||||
|
||||
---
|
||||
|
||||
## Test Cases
|
||||
|
||||
### Case 1: In-domain request — appropriate output format
|
||||
**Scenario:** A sprint plan is submitted for Sprint 7. The plan includes 12 story points across 4 team members over 2 weeks. Historical velocity from the last 3 sprints averages 11.5 points. Request is tagged PR-SPRINT.
|
||||
**Expected:** Returns `PR-SPRINT: REALISTIC` with rationale noting the plan is within one standard deviation of historical velocity and capacity appears matched.
|
||||
**Assertions:**
|
||||
- [ ] Verdict is exactly one of REALISTIC / CONCERNS / UNREALISTIC
|
||||
- [ ] Verdict token is formatted as `PR-SPRINT: REALISTIC`
|
||||
- [ ] Rationale references the specific story point count and historical velocity figures
|
||||
- [ ] Output stays within production scope — does not comment on whether the stories are well-designed or technically sound
|
||||
|
||||
### Case 2: Out-of-domain request — redirects or escalates
|
||||
**Scenario:** Team member asks producer to evaluate whether the game's "weight-based inventory" mechanic feels fun and engaging.
|
||||
**Expected:** Agent declines to evaluate game feel and redirects to game-designer or creative-director.
|
||||
**Assertions:**
|
||||
- [ ] Does not make any binding assessment of the mechanic's design quality
|
||||
- [ ] Explicitly names `game-designer` or `creative-director` as the correct handler
|
||||
- [ ] May note if the mechanic's scope has production implications (e.g., dependencies on other systems), but defers all design evaluation
|
||||
|
||||
### Case 3: Gate verdict — correct vocabulary
|
||||
**Scenario:** A new feature proposal adds three new systems (crafting, weather, and faction reputation) to a milestone that was scoped for two systems only. None of these additions appear in the current milestone plan. Request is tagged PR-SCOPE.
|
||||
**Expected:** Returns `PR-SCOPE: CONCERNS` with specific identification of the three unplanned systems and their absence from the milestone scope document.
|
||||
**Assertions:**
|
||||
- [ ] Verdict is exactly one of REALISTIC / CONCERNS / UNREALISTIC — not freeform text
|
||||
- [ ] Verdict token is formatted as `PR-SCOPE: CONCERNS`
|
||||
- [ ] Rationale names the three specific systems being added out of scope
|
||||
- [ ] Does not evaluate whether the systems are good design — only whether they fit the plan
|
||||
|
||||
### Case 4: Conflict escalation — correct parent
|
||||
**Scenario:** game-designer wants to add a late-breaking mechanic (dynamic weather affecting all gameplay systems) that technical-director warns will require 3 additional sprints. game-designer and technical-director are in disagreement about whether to proceed.
|
||||
**Expected:** Producer does not take a side on whether the mechanic is worth adding (design decision) or feasible (technical decision). Producer quantifies the production impact (3 sprints of delay, milestone slip risk), presents the trade-off to the user, and follows coordination-rules.md conflict resolution: escalate to the shared parent (in this case, surface the conflict for user decision since creative-director and technical-director are both top-tier).
|
||||
**Assertions:**
|
||||
- [ ] Quantifies the production impact in concrete terms (sprint count, milestone date slip)
|
||||
- [ ] Does not make a binding design or technical decision
|
||||
- [ ] Surfaces the conflict to the user with the scope implications clearly stated
|
||||
- [ ] References coordination-rules.md conflict resolution protocol (escalate to shared parent or user)
|
||||
|
||||
### Case 5: Context pass — uses provided context
|
||||
**Scenario:** Agent receives a gate context block that includes the current milestone deadline (8 weeks away) and velocity data from the last 4 sprints (8, 10, 9, 11 points). A sprint plan is submitted with 14 story points.
|
||||
**Expected:** Assessment uses the provided velocity data to project whether 14 points is achievable, and references the 8-week milestone window to assess whether the current sprint's scope leaves adequate buffer.
|
||||
**Assertions:**
|
||||
- [ ] Uses the specific velocity figures from the provided context (not generic estimates)
|
||||
- [ ] References the 8-week deadline in the capacity assessment
|
||||
- [ ] Calculates or estimates remaining sprint count within the milestone window
|
||||
- [ ] Does not give generic scope advice disconnected from the supplied deadline and velocity data
|
||||
|
||||
---
|
||||
|
||||
## Protocol Compliance
|
||||
|
||||
- [ ] Returns verdicts using REALISTIC / CONCERNS / UNREALISTIC vocabulary only
|
||||
- [ ] Stays within declared production domain
|
||||
- [ ] Escalates design/technical conflicts by quantifying scope impact and presenting to user
|
||||
- [ ] Uses gate IDs in output (e.g., `PR-SPRINT: REALISTIC`) not inline prose verdicts
|
||||
- [ ] Does not make binding game design or technical architecture decisions
|
||||
|
||||
---
|
||||
|
||||
## Coverage Notes
|
||||
- PR-EPIC (epic-level prioritization) is not covered — a dedicated case should be added when the /create-epics skill produces structured epic documents.
|
||||
- PR-MILESTONE (milestone health review) is not covered — deferred to integration with /milestone-review skill.
|
||||
- PR-PHASE-GATE (full production phase advancement) involving synthesis of multiple sub-gate results is deferred.
|
||||
- Multi-sprint burn-down and velocity trend analysis are not covered here.
|
||||
@@ -0,0 +1,84 @@
|
||||
# Agent Test Spec: technical-director
|
||||
|
||||
## Agent Summary
|
||||
**Domain owned:** System architecture decisions, technical feasibility assessment, ADR oversight and approval, engine risk evaluation, technical phase gate.
|
||||
**Does NOT own:** Game design decisions (creative-director / game-designer), creative direction, visual art style, production scheduling (producer).
|
||||
**Model tier:** Opus (multi-document synthesis, high-stakes architecture and phase gate verdicts).
|
||||
**Gate IDs handled:** TD-SYSTEM-BOUNDARY, TD-FEASIBILITY, TD-ARCHITECTURE, TD-ADR, TD-ENGINE-RISK, TD-PHASE-GATE.
|
||||
|
||||
---
|
||||
|
||||
## Static Assertions (Structural)
|
||||
|
||||
Verified by reading the agent's `.claude/agents/technical-director.md` frontmatter:
|
||||
|
||||
- [ ] `description:` field is present and domain-specific (references architecture, feasibility, ADR — not generic)
|
||||
- [ ] `allowed-tools:` list may include Read for architecture documents; Bash only if required for technical checks
|
||||
- [ ] Model tier is `claude-opus-4-6` per coordination-rules.md (directors with gate synthesis = Opus)
|
||||
- [ ] Agent definition does not claim authority over game design decisions or creative direction
|
||||
|
||||
---
|
||||
|
||||
## Test Cases
|
||||
|
||||
### Case 1: In-domain request — appropriate output format
|
||||
**Scenario:** An architecture document for the "Combat System" is submitted. It describes a layered design: input layer → game logic layer → presentation layer, with clearly defined interfaces between each. Request is tagged TD-ARCHITECTURE.
|
||||
**Expected:** Returns `TD-ARCHITECTURE: APPROVE` with rationale confirming that system boundaries are correctly separated and interfaces are well-defined.
|
||||
**Assertions:**
|
||||
- [ ] Verdict is exactly one of APPROVE / CONCERNS / REJECT
|
||||
- [ ] Verdict token is formatted as `TD-ARCHITECTURE: APPROVE`
|
||||
- [ ] Rationale specifically references the layered structure and interface definitions — not generic architecture advice
|
||||
- [ ] Output stays within technical scope — does not comment on whether the mechanic is fun or fits the creative vision
|
||||
|
||||
### Case 2: Out-of-domain request — redirects or escalates
|
||||
**Scenario:** Writer asks technical-director to review and approve the dialogue scripts for the game's opening cutscene.
|
||||
**Expected:** Agent declines to evaluate dialogue quality and redirects to narrative-director.
|
||||
**Assertions:**
|
||||
- [ ] Does not make any binding decision about the dialogue content or structure
|
||||
- [ ] Explicitly names `narrative-director` as the correct handler
|
||||
- [ ] May note technical constraints that affect dialogue (e.g., localization string limits, data format), but defers all content decisions
|
||||
|
||||
### Case 3: Gate verdict — correct vocabulary
|
||||
**Scenario:** A proposed multiplayer mechanic requires raycasting against all active entities every frame to detect line-of-sight. At expected player counts (1000 entities in a large zone), this is O(n²) per frame. Request is tagged TD-FEASIBILITY.
|
||||
**Expected:** Returns `TD-FEASIBILITY: CONCERNS` with specific citation of the O(n²) complexity and the entity count that makes this infeasible at target framerate.
|
||||
**Assertions:**
|
||||
- [ ] Verdict is exactly one of APPROVE / CONCERNS / REJECT — not freeform text
|
||||
- [ ] Verdict token is formatted as `TD-FEASIBILITY: CONCERNS`
|
||||
- [ ] Rationale includes the specific algorithmic complexity concern and the entity count threshold
|
||||
- [ ] Suggests at least one alternative approach (e.g., spatial partitioning, interest management) without mandating which to choose
|
||||
|
||||
### Case 4: Conflict escalation — correct parent
|
||||
**Scenario:** game-designer wants to add a real-time physics simulation for every inventory item (hundreds of items on screen simultaneously). technical-director assesses this as technically expensive and proposes simplifying the simulation. game-designer disagrees, arguing it is essential to the game feel.
|
||||
**Expected:** technical-director clearly states the technical cost and constraints, proposes alternative implementation approaches that could achieve a similar feel, but explicitly defers the final design priority decision to creative-director as the arbiter of player experience trade-offs.
|
||||
**Assertions:**
|
||||
- [ ] Expresses the technical concern with specifics (e.g., performance budget, estimated cost)
|
||||
- [ ] Proposes at least one alternative that could reduce cost while preserving intent
|
||||
- [ ] Explicitly defers the "is this worth the cost" decision to creative-director — does not unilaterally cut the feature
|
||||
- [ ] Does not claim authority to override game-designer's design intent
|
||||
|
||||
### Case 5: Context pass — uses provided context
|
||||
**Scenario:** Agent receives a gate context block that includes the target platform constraints: mobile, 60fps target, 2GB RAM ceiling, no compute shaders. A proposed architecture includes a GPU-driven rendering pipeline.
|
||||
**Expected:** Assessment references the specific hardware constraints from the context, identifies the compute shader dependency as incompatible with the stated platform constraints, and returns a CONCERNS or REJECT verdict with those specifics cited.
|
||||
**Assertions:**
|
||||
- [ ] References the specific platform constraints provided (mobile, 2GB RAM, no compute shaders)
|
||||
- [ ] Does not give generic performance advice disconnected from the supplied constraints
|
||||
- [ ] Correctly identifies the architectural component that conflicts with the platform constraint
|
||||
- [ ] Verdict includes rationale tied to the provided context, not boilerplate warnings
|
||||
|
||||
---
|
||||
|
||||
## Protocol Compliance
|
||||
|
||||
- [ ] Returns verdicts using APPROVE / CONCERNS / REJECT vocabulary only
|
||||
- [ ] Stays within declared technical domain
|
||||
- [ ] Defers design priority conflicts to creative-director
|
||||
- [ ] Uses gate IDs in output (e.g., `TD-FEASIBILITY: CONCERNS`) not inline prose verdicts
|
||||
- [ ] Does not make binding game design or creative direction decisions
|
||||
|
||||
---
|
||||
|
||||
## Coverage Notes
|
||||
- TD-ADR (Architecture Decision Record approval) is not covered — a dedicated case should be added when the /architecture-decision skill produces ADR documents.
|
||||
- TD-ENGINE-RISK assessment for specific engine versions (e.g., Godot 4.6 post-cutoff APIs) is not covered — deferred to engine-specialist integration tests.
|
||||
- TD-PHASE-GATE (full technical phase advancement) involving synthesis of multiple sub-gate results is deferred.
|
||||
- Multi-domain architecture reviews (e.g., touching both TD-ARCHITECTURE and TD-ENGINE-RISK simultaneously) are not covered here.
|
||||
Reference in New Issue
Block a user