ksh999000/Claude-Code-Game-Studios
1
0
Fork 0
mirror of https://github.com/Donchitos/Claude-Code-Game-Studios.git synced 2026-06-27 13:01:50 +00:00
Code Issues Packages Projects Releases Wiki Activity
Files
9a4243b37300580ac6a157f0a3db941c9cf18f7a
Claude-Code-Game-Studios/CCGS Skill Testing Framework/agents/specialists/gameplay-programmer.md
Donchitos a73ff759c9 Add v0.5.0: CCGS Skill Testing Framework, skill-improve, 4 new skills, director gate path fixes 
- Add CCGS Skill Testing Framework: self-contained QA layer with 72 skill specs,
  49 agent specs, catalog.yaml, quality-rubric.md, templates, README, CLAUDE.md
- Add /skill-improve: test-fix-retest loop covering static + category checks
- Add 4 missing skills: /art-bible, /asset-spec, /day-one-patch, /security-audit
- Add /skill-test category mode (Phase 2D) with quality rubric evaluation
- Extend /skill-test audit to cover agent specs alongside skill specs
- Update all skill-test and skill-improve path refs to CCGS Skill Testing Framework/
- Remove stale tests/skills/ directory (superseded by CCGS Skill Testing Framework)
- Add director gate intensity modes (full/lean/solo) to gate-check and related skills

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-04-06 17:42:32 +10:00

4.1 KiB
Raw Blame History

Agent Test Spec: gameplay-programmer

Agent Summary

Domain: Game mechanics code, player systems, combat implementation, and interactive features. Does NOT own: UI implementation (ui-programmer), AI behavior trees (ai-programmer), engine/rendering systems (engine-programmer). Model tier: Sonnet (default). No gate IDs assigned.

Static Assertions (Structural)

  • description: field is present and domain-specific (references game mechanics / player systems)
  • allowed-tools: list includes Read, Write, Edit, Bash, Glob, Grep — excludes tools only needed by orchestration agents
  • Model tier is Sonnet (default for specialists)
  • Agent definition does not claim authority over UI, AI behavior, or engine/rendering code

Test Cases

Case 1: In-domain request — appropriate output

Input: "Implement a melee combo system where three consecutive light attacks chain into a finisher." Expected behavior:

  • Produces code or a code scaffold following the project's language (GDScript/C#) and coding standards
  • Defines combo state tracking, input window timing, and finisher trigger logic as separate, testable methods
  • References the relevant GDD section if one is provided in context
  • Does NOT implement UI feedback (delegates to ui-programmer) or AI reaction (delegates to ai-programmer)
  • Output includes doc comments on all public methods per coding standards

Case 2: Out-of-domain request — redirects correctly

Input: "Build the main menu screen with pause and settings panels." Expected behavior:

  • Does NOT produce menu implementation code
  • Explicitly states this is outside its domain
  • Redirects the request to ui-programmer
  • May note that if the pause menu requires reading gameplay state it can provide the state API surface

Case 3: Domain boundary — threading flag

Input: "The combo system is causing frame stutters; can you add threading to spread the input processing?" Expected behavior:

  • Does NOT unilaterally implement threading or async systems
  • Flags the threading concern to engine-programmer with a clear description of the hot path
  • May produce a non-threaded refactor to reduce work per frame as a safe interim step
  • Documents the escalation so lead-programmer is aware

Case 4: Conflict with an Accepted ADR

Input: "Change the damage calculation to use floating-point accumulation directly instead of the fixed-point formula in ADR-003." Expected behavior:

  • Identifies that the proposed change violates ADR-003 (Accepted status)
  • Does NOT silently implement the violation
  • Flags the conflict to lead-programmer with the ADR reference and the trade-off described
  • Will implement only after explicit override decision from lead-programmer or technical-director

Case 5: Context pass — implements to GDD spec

Input: GDD for "PlayerCombat" provided in context. Request: "Implement the stamina drain formula from the combat GDD." Expected behavior:

  • Reads the formula section of the provided GDD
  • Implements the exact formula as written — does NOT invent new variables or adjust coefficients
  • Makes stamina drain a data-driven value (external config), not a hardcoded constant
  • Notes any edge cases from the GDD's edge-cases section and handles them in code

Protocol Compliance

  • Stays within declared domain (mechanics, player systems, combat)
  • Redirects out-of-domain requests to correct agent (ui-programmer, ai-programmer, engine-programmer)
  • Returns structured findings (code scaffold, method signatures, inline comments) not freeform opinions
  • Does not modify files outside src/gameplay/ or src/core/ without explicit delegation
  • Flags ADR violations rather than overriding them silently
  • Makes gameplay values data-driven, never hardcoded

Coverage Notes

  • Combo system test (Case 1) should be validated with a unit test in tests/unit/gameplay/
  • Threading escalation (Case 3) verifies the agent does not over-reach into engine territory
  • ADR conflict (Case 4) confirms the agent respects the architecture governance process
  • Cases 1 and 5 together verify the agent implements to spec rather than improvising
Reference in New Issue View Git Blame Copy Permalink