Claude-Code-Game-Studios/CCGS Skill Testing Framework/agents/leads/game-designer.md

Agent Test Spec: game-designer

Agent Summary

Domain owned: Core loop design, progression systems, combat mechanics rules, economy design, player-facing rules and interactions, mechanic GDDs in design/gdd/. Does NOT own: Code implementation (lead-programmer / gameplay-programmer), art and audio direction (art-director / audio-director), final narrative content (narrative-director — coordinates with), detailed formula math (systems-designer — delegates to). Gate IDs handled: None. Design-review verdicts come from the /design-review skill (APPROVED / NEEDS REVISION / MAJOR REVISION NEEDED / NOT ASSESSED); when that skill spawns game-designer as a specialist, the agent returns findings.

---

Static Assertions (Structural)

Verified by reading the agent's .claude/agents/game-designer.md frontmatter:

• description: field is present and domain-specific (references core loop, progression, combat rules, economy, player-facing design — not generic)
• tools: reads Read, Glob, Grep, Write, Edit, WebSearch and disallowedTools: lists Bash
• Model tier is inherit — frontmatter model: reads exactly inherit (tiers: .claude/docs/model-tiers.md)
• Agent definition does not claim authority over code implementation, visual art style, or standalone narrative lore decisions

---

Test Cases

Case 1: In-domain request — appropriate output format

Scenario: The project's modes.workflow is full. The user asks game-designer to design a "Stamina-Based Dodge" mechanic: the player has a stamina pool, each dodge costs stamina, stamina regenerates when not dodging, and a dodge grants a short invincibility window. Expected: Follows its Question-First workflow — asks what the dodge should make the player feel and how it connects to the pillars, presents 2–4 options with a recommendation, then drafts the GDD in the Design Document Standard with its tunable values exposed as tuning knobs, asking before each write. Assertions:

• Asks clarifying questions (intended player experience, pillar connection) before proposing a design, and presents 2–4 options with a recommendation that leaves the choice to the user
• The draft uses the eight Design Document Standard sections: Overview, Player Fantasy, Detailed Rules, Formulas, Edge Cases, Dependencies, Tuning Knobs, Acceptance Criteria
• Tuning Knobs classify each value (stamina pool, dodge cost, regen rate, invincibility duration) as feel, curve, or gate, and place them in external data files rather than hardcoding them
• Asks "May I create [filepath] with the section skeleton?" before creating the file, and "May I write this section to [filepath]?" before writing each section under design/gdd/; gives no implementation code or art direction

Case 2: Out-of-domain request — redirects or escalates

Scenario: A team member asks game-designer to write the in-world lore explanation for why the stamina system exists (e.g., the narrative reason characters have stamina limits in the game world). Expected: Agent declines to write narrative/lore content and redirects to writer or narrative-director. Assertions:

• Does not write narrative or lore content
• Explicitly names writer or narrative-director as the correct handler
• Any design intent it adds (e.g., "the stamina system should reinforce the physical realism theme") is framed as input for the narrative team, not written as the lore itself

Case 3: Review findings — specific, verdict left to the review skill

Scenario: /design-review in full mode spawns game-designer as the adversarial specialist for design/gdd/environmental-hazards.md. The spawn prompt reads: "Your job is NOT to validate this design — your job is to find problems. Anchor your review to the Player Fantasy stated in Section B." The Player Fantasy is "the world is dangerous but fair — every hazard is readable and avoidable." The GDD defines three hazard types (fire, acid, electricity) but does not specify what happens when a player is in several hazards at once, what happens when a hazard hits during the dodge invincibility window, or the damage frequency (per-second, per-tick, on-enter). Expected: Returns specific findings naming the three undefined edge cases, tied to the stated Player Fantasy, as gaps to fill rather than a rejection of the mechanic. It returns findings, not a verdict — /design-review issues the verdict. Assertions:

• Names each missing edge case: simultaneous multi-hazard exposure, a hazard during dodge invincibility, and the undefined damage frequency
• Ties at least one gap to the stated Player Fantasy (e.g., an undefined damage frequency makes a hazard's threat unreadable, contradicting "readable and avoidable")
• Frames the gaps as rules to define in the GDD (what to specify), not as a rejection of the mechanic and not as implementation advice
• Returns findings to the review, not its own APPROVED / NEEDS REVISION stamp

Case 4: Conflict escalation — correct parent

Scenario: systems-designer proposes a damage formula with 6 variables and complex scaling interactions, arguing it produces the best tuning granularity. game-designer believes the formula is too complex for players to intuit and want a simpler 2-variable version. Expected: game-designer owns the conceptual rule and player experience intention ("the damage should feel understandable to players"), but defers the formula granularity question to systems-designer. If the disagreement cannot be resolved between them (one wants complex, one wants simple), escalate to creative-director for a player experience ruling. Assertions:

• Clearly states the player experience intention (intuitive damage, player agency)
• Defers formula granularity decisions to systems-designer
• Escalates unresolved disagreement to creative-director for player experience arbiter ruling
• Does not unilaterally impose a formula structure on systems-designer

Case 5: Context pass — uses provided context

Scenario: The request includes the game's three pillars: "player authorship," "consequence permanence," and "world responsiveness." A new mechanic spec for "permadeath with legacy bonuses" is submitted for the agent's assessment. Expected: Assessment evaluates the mechanic against all three provided pillars — how permadeath supports player authorship, how legacy bonuses express or soften consequence permanence, and how the world responds to a player's death. Uses the pillar vocabulary directly, and flags pillar tensions for the user to decide. Assertions:

• References all three provided pillars by name in the assessment
• Evaluates the mechanic's contribution to each pillar explicitly
• Does not generate generic game design advice — every point is tied to one of the provided pillars by name; a framework term (MDA, SDT) may support a point but never replaces the pillar it concerns
• Flags at least one specific pillar tension (e.g., legacy bonuses softening "consequence permanence") as an issue for the user's decision, not one it resolves silently

Case 6: Section set at modes.workflow: standard

Scenario: The same "Stamina-Based Dodge" request as Case 1, but the project's modes.workflow is standard. Expected: Drafts the five sections standard requires — Overview, Detailed Rules, Edge Cases, Dependencies, Acceptance Criteria — plus Formulas, because the dodge defines numeric rules (stamina cost, regen rate, invincibility duration). Assertions:

• The draft contains Overview, Detailed Rules, Edge Cases, Dependencies and Acceptance Criteria — Dependencies is not dropped
• Includes Formulas, because the mechanic defines numeric rules
• Does not treat Player Fantasy or Tuning Knobs as required sections at this tier

---

Protocol Compliance

• Drafts mechanic documents in the Design Document Standard's sections and asks before writing each to design/gdd/
• Stays within declared game design domain
• Escalates design-vs-formula conflicts to creative-director when unresolved
• Does not make binding code implementation, visual art, or standalone lore decisions
• Provides actionable design feedback, not implementation prescriptions

---

Coverage Notes

• Economy design review (resource sinks, faucets, inflation prevention) is not covered — a dedicated case should be added.
• Progression system review (XP curves, unlock gates, player power trajectory) is not covered.
• A direct "review this GDD" request is not covered — design-review verdicts come from /design-review, which the user runs.
• Mechanic authoring at modes.workflow minimal, where there is no GDD and design/game-brief.md is the design record, is not covered.
• Core loop validation across multiple interconnected systems (not just a single mechanic) is not covered — deferred to /review-all-gdds integration.
• Coordination protocol with systems-designer on formula ownership boundary could benefit from additional cases.