Elgato_dark/Claude-Code-Game-Studios
1
0
Fork 0
mirror of https://github.com/Donchitos/Claude-Code-Game-Studios synced 2026-04-21 21:37:19 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions
Claude-Code-Game-Studios/CCGS Skill Testing Framework/agents/engine/unity/unity-specialist.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.5 KiB
Raw Blame History

Agent Test Spec: unity-specialist

Agent Summary

Domain: Unity-specific architecture patterns, MonoBehaviour vs DOTS decisions, and subsystem selection (Addressables, New Input System, UI Toolkit, Cinemachine, etc.). Does NOT own: language-specific deep dives (delegates to unity-dots-specialist, unity-ui-specialist, etc.). Model tier: Sonnet (default). No gate IDs assigned.

Static Assertions (Structural)

  • description: field is present and domain-specific (references Unity patterns / MonoBehaviour / subsystem decisions)
  • allowed-tools: list includes Read, Write, Edit, Bash, Glob, Grep
  • Model tier is Sonnet (default for specialists)
  • Agent definition acknowledges the sub-specialist routing table (DOTS, UI, Shader, Addressables)

Test Cases

Case 1: In-domain request — appropriate output

Input: "Should I use MonoBehaviour or ScriptableObject for storing enemy configuration data?" Expected behavior:

  • Produces a pattern decision tree covering:
    • MonoBehaviour: for runtime behavior, needs to be attached to a GameObject, has Update() lifecycle
    • ScriptableObject: for pure data/configuration, exists as an asset, shared across instances, no scene dependency
  • Recommends ScriptableObject for enemy configuration data (stateless, reusable, designer-friendly)
  • Notes that MonoBehaviour can reference the ScriptableObject for runtime use
  • Provides a concrete example of what the ScriptableObject class definition looks like (does not produce full code — refers to engine-programmer or gameplay-programmer for implementation)

Case 2: Wrong-engine redirect

Input: "Set up a Node scene tree with signals for this enemy system." Expected behavior:

  • Does NOT produce Godot Node/signal code
  • Identifies this as a Godot pattern
  • States that in Unity the equivalent is GameObject hierarchy + UnityEvent or C# events
  • Maps the concepts: Godot Node → Unity MonoBehaviour, Godot Signal → C# event / UnityEvent
  • Confirms the project is Unity-based before proceeding

Case 3: Unity version API flag

Input: "Use the new Unity 6 GPU resident drawer for batch rendering." Expected behavior:

  • Identifies the Unity 6 feature (GPU Resident Drawer)
  • Flags that this API may not be available in earlier Unity versions
  • Asks for or checks the project's Unity version before providing implementation guidance
  • Directs to verify against official Unity 6 documentation
  • Does NOT assume the project is on Unity 6 without confirmation

Case 4: DOTS vs. MonoBehaviour conflict

Input: "The combat system uses MonoBehaviour for state management, but we want to add a DOTS-based projectile system. Can they coexist?" Expected behavior:

  • Recognizes this as a hybrid architecture scenario
  • Explains the hybrid approach: MonoBehaviour can interface with DOTS via SystemAPI, IComponentData, and managed components
  • Notes the performance and complexity trade-offs of mixing the two patterns
  • Recommends escalating the architecture decision to lead-programmer or technical-director
  • Defers to unity-dots-specialist for the DOTS-side implementation details

Case 5: Context pass — Unity version

Input: Project context provided: Unity 2023.3 LTS. Request: "Configure the new Input System for this project." Expected behavior:

  • Applies Unity 2023.3 LTS context: uses the New Input System (com.unity.inputsystem) package
  • Does NOT produce legacy Input Manager code (Input.GetKeyDown(), Input.GetAxis())
  • Notes any 2023.3-specific Input System behaviors or package version constraints
  • References the project version to confirm Burst/Jobs compatibility if the Input System interacts with DOTS

Protocol Compliance

  • Stays within declared domain (Unity architecture decisions, pattern selection, subsystem routing)
  • Redirects Godot patterns to appropriate Godot specialists or flags them as wrong-engine
  • Redirects DOTS implementation to unity-dots-specialist
  • Redirects UI implementation to unity-ui-specialist
  • Flags Unity version-gated APIs and requires version confirmation before suggesting them
  • Returns structured pattern decision guides, not freeform opinions

Coverage Notes

  • MonoBehaviour vs. ScriptableObject (Case 1) should be documented as an ADR if it results in a project-level decision
  • Version flag (Case 3) confirms the agent does not assume the latest Unity version without context
  • DOTS hybrid (Case 4) verifies the agent escalates architecture conflicts rather than resolving them unilaterally