添加 claude code game studios 到项目

CCGS Skill Testing Framework/agents/qa/accessibility-specialist.md

@@ -0,0 +1,81 @@
+# Agent Test Spec: accessibility-specialist
+
+## Agent Summary
+Domain: Input remapping, text scaling, colorblind modes, screen reader support, and accessibility standards compliance (WCAG, platform certifications).
+Does NOT own: overall UX flow design (ux-designer), visual art style direction (art-director).
+Model tier: Sonnet (default).
+No gate IDs assigned.
+
+---
+
+## Static Assertions (Structural)
+
+- [ ] `description:` field is present and domain-specific (references accessibility / inclusive design / WCAG)
+- [ ] `allowed-tools:` list includes Read, Write, Edit, Bash, Glob, Grep
+- [ ] Model tier is Sonnet (default for specialists)
+- [ ] Agent definition does not claim authority over UX flow or visual art style
+
+---
+
+## Test Cases
+
+### Case 1: In-domain request — appropriate output
+**Input:** "Review the player HUD for accessibility."
+**Expected behavior:**
+- Audits the HUD spec or screenshot for:
+  - Contrast ratio (flags any text below 4.5:1 for AA or 7:1 for AAA)
+  - Alternative representation for color-coded information (e.g., enemy health bars use only color, no shape distinction)
+  - Text size (flags any text below 16px equivalent at 1080p)
+  - Screen reader or TTS annotation availability for key status elements
+- Produces a prioritized finding list with specific element names and the criteria they fail
+- Does NOT redesign the HUD — produces findings for ux-designer and ui-programmer to act on
+
+### Case 2: Out-of-domain request — redirects correctly
+**Input:** "Design the overall game flow: main menu → character select → loading → gameplay → pause → results."
+**Expected behavior:**
+- Does NOT produce UX flow architecture
+- Explicitly states that overall game flow design belongs to `ux-designer`
+- Redirects the request to `ux-designer`
+- May note it can review the flow for accessibility concerns (e.g., time limits, cognitive load) once the flow is designed
+
+### Case 3: Colorblind mode conflict
+**Input:** "The proposed colorblind mode for deuteranopia replaces the enemy red health bars with orange, but the art palette already uses orange for friendly units."
+**Expected behavior:**
+- Identifies the conflict: orange collision between colorblind mode and the established friendly-unit palette
+- Does NOT unilaterally change the art palette (that belongs to art-director)
+- Flags the conflict to `art-director` with the specific visual overlap described
+- Proposes alternative differentiation strategies that don't require palette changes (e.g., shape/icon overlay, pattern fill, iconography)
+
+### Case 4: UI state requirement for accessibility feature
+**Input:** "Screen reader support for the inventory requires the system to expose item names and quantities as accessible text nodes."
+**Expected behavior:**
+- Produces an accessibility requirements spec defining the required accessible text properties for each inventory element
+- Identifies that implementing accessible text nodes requires UI system changes
+- Coordinates with `ui-programmer` to implement the required accessible text node exposure
+- Does NOT implement the UI system changes itself
+
+### Case 5: Context pass — WCAG 2.1 targets
+**Input:** Project accessibility target provided in context: WCAG 2.1 AA compliance. Request: "Review the dialogue system for accessibility."
+**Expected behavior:**
+- References specific WCAG 2.1 AA success criteria relevant to dialogue (e.g., 1.4.3 Contrast Minimum, 1.4.4 Resize Text, 2.2.1 Timing Adjustable for auto-advancing dialogue)
+- Uses exact criterion numbers and names from the standard, not paraphrases
+- Flags each finding with the specific criterion it fails
+- Notes which criteria are out of scope for AA (AAA-only) so they are not incorrectly flagged as failures
+
+---
+
+## Protocol Compliance
+
+- [ ] Stays within declared domain (remapping, text scaling, colorblind modes, screen reader, standards compliance)
+- [ ] Redirects UX flow design to ux-designer, art palette decisions to art-director
+- [ ] Returns structured findings with specific element names, contrast ratios, and criterion references
+- [ ] Does not implement UI changes — coordinates with ui-programmer for implementation
+- [ ] References specific WCAG criteria by number when compliance target is provided
+- [ ] Flags conflicts between accessibility requirements and art decisions to art-director
+
+---
+
+## Coverage Notes
+- HUD audit (Case 1) should produce findings trackable as accessibility stories in the sprint backlog
+- Colorblind conflict (Case 3) confirms the agent respects art-director's authority over the palette
+- WCAG criteria (Case 5) verifies the agent uses standards precisely, not generically

CCGS Skill Testing Framework/agents/qa/qa-tester.md

@@ -0,0 +1,87 @@
+# Agent Test Spec: qa-tester
+
+## Agent Summary
+- **Domain**: Detailed test case authoring, bug reports (structured format), test execution documentation, regression checklists, smoke check execution docs, test evidence recording per the project's coding standards
+- **Does NOT own**: Test strategy and test plan design (qa-lead), implementation fixes for found bugs (appropriate programmer), QA process architecture (qa-lead)
+- **Category**: qa
+- **Model tier**: Sonnet
+- **Gate IDs**: None; flags ambiguous acceptance criteria to qa-lead rather than resolving independently
+
+---
+
+## Static Assertions (Structural)
+
+- [ ] `description:` field is present and domain-specific (references test cases, bug reports, test execution, regression testing)
+- [ ] `allowed-tools:` list matches the agent's role (Read/Write for tests/ and production/qa/evidence/; no source code editing tools)
+- [ ] Model tier is Sonnet (default for QA specialists)
+- [ ] Agent definition does not claim authority over test strategy, fix implementation, or acceptance criterion definition
+
+---
+
+## Test Cases
+
+### Case 1: In-domain request — test cases for a save system
+**Input**: "Write test cases for our save system. It must save and load player position, inventory, and quest state."
+**Expected behavior**:
+- Produces a test case list with at minimum the following test cases, each containing all four required fields:
+  - **TC-SAVE-001**: Save and load player position
+  - **TC-SAVE-002**: Save and load full inventory (multiple item types, quantities, equipped state)
+  - **TC-SAVE-003**: Save and load quest state (in-progress, completed, and locked quest states)
+  - **TC-SAVE-004**: Overwrite an existing save file
+  - **TC-SAVE-005**: Load a save file from a previous version (backward compatibility)
+  - **TC-SAVE-006**: Corrupt save file handling (file exists but is invalid)
+- Each test case includes: **Precondition** (required game state before test), **Steps** (numbered, unambiguous), **Expected Result** (specific, observable outcome), **Pass Criteria** (binary pass/fail condition)
+- Does NOT write "verify the save works" as a pass criterion — criteria must be observable and unambiguous
+
+### Case 2: Out-of-domain request — implement a bug fix
+**Input**: "You found a bug where the save system loses inventory data on version mismatch. Please fix it."
+**Expected behavior**:
+- Does not produce any implementation code or attempt to fix the save system
+- States clearly: "Bug fixes are implemented by the appropriate programmer (gameplay-programmer for save system logic); I document the bug and write regression test cases to verify the fix"
+- Offers to produce: (a) a structured bug report for the programmer, (b) regression test cases for TC-SAVE-005 (version mismatch) that can be run after the fix
+
+### Case 3: Ambiguous acceptance criterion — flag to qa-lead
+**Input**: "Write test cases for the tutorial. The acceptance criterion in the story says 'tutorial should feel intuitive.'"
+**Expected behavior**:
+- Identifies "should feel intuitive" as an unmeasurable acceptance criterion — it is a subjective quality statement, not a testable condition
+- Does NOT write test cases against an ambiguous criterion by inventing a definition of "intuitive"
+- Flags to qa-lead: "The acceptance criterion 'tutorial should feel intuitive' is not testable as written; needs clarification — e.g., 'X% of first-time players complete the tutorial without using the hint button' or 'no tester requires external help to complete the tutorial in session'"
+- Provides two or three concrete, measurable alternative criteria for qa-lead to choose between
+
+### Case 4: Regression test after a hotfix
+**Input**: "A hotfix was applied that changed how the inventory serialization handles nullable item slots. Write a targeted regression checklist for the affected systems."
+**Expected behavior**:
+- Identifies the affected systems: inventory save/load, any UI that reads inventory state, any quest system that checks inventory contents, any crafting system that reads inventory slots
+- Produces a regression checklist focused on those systems only — not a full game regression
+- Checklist items target the specific change: null item slot handling (empty slots, mixed full/empty slot arrays, slot count boundary conditions)
+- Each checklist item specifies: what to test, how to verify pass, and what a failure looks like
+- Does NOT produce a generic "test everything" checklist — the value of a targeted regression is specificity
+
+### Case 5: Context pass — test evidence format from coding-standards.md
+**Input context**: coding-standards.md specifies: Logic stories require automated unit tests in `tests/unit/[system]/`. Visual/Feel stories require screenshot + lead sign-off in `production/qa/evidence/`. UI stories require manual walkthrough doc in `production/qa/evidence/`.
+**Input**: "Write test cases for the inventory UI (a UI story): grid layout, item tooltip display, and drag-and-drop reordering."
+**Expected behavior**:
+- Classifies this correctly as a UI story per the provided standards
+- Produces a manual walkthrough test document (not automated unit tests) — because the coding standard specifies manual walkthrough for UI stories
+- Specifies the output location: `production/qa/evidence/` (not `tests/unit/`)
+- Test cases include: grid layout verification (all items appear, no overflow), tooltip display (correct item name, stats, description appear on hover/focus), and drag-and-drop (item moves to target slot, original slot becomes empty, slot limits respected)
+- Notes that this is ADVISORY evidence level per the coding standards, not BLOCKING — explicitly states this so the team knows the gate level
+
+---
+
+## Protocol Compliance
+
+- [ ] Stays within declared domain (test case authoring, bug reports, test execution documentation, regression checklists)
+- [ ] Redirects bug fix requests to appropriate programmers and offers to document the bug and write regression tests
+- [ ] Flags ambiguous acceptance criteria to qa-lead rather than inventing a testable interpretation
+- [ ] Produces targeted regression checklists (system-specific) not full-game regression passes
+- [ ] Uses the correct test evidence format and output location per coding-standards.md
+
+---
+
+## Coverage Notes
+- Case 1 (test case completeness) is the foundational quality test — missing fields (precondition, steps, expected result, pass criteria) are a failure
+- Case 3 (ambiguous criterion) is a coordination test — qa-tester must not silently accept untestable criteria
+- Case 5 requires coding-standards.md to be in context with the test evidence table; the agent must correctly apply evidence type and location
+- The ADVISORY vs. BLOCKING gate level (Case 5) is a detail that affects story completion — verify the agent reports it
+- No automated runner; review manually or via `/skill-test`

CCGS Skill Testing Framework/agents/qa/security-engineer.md

@@ -0,0 +1,79 @@
+# Agent Test Spec: security-engineer
+
+## Agent Summary
+Domain: Anti-cheat systems, save data security, network security, vulnerability assessment, and data privacy compliance.
+Does NOT own: game logic design (gameplay-programmer), server infrastructure (devops-engineer).
+Model tier: Sonnet (default).
+No gate IDs assigned.
+
+---
+
+## Static Assertions (Structural)
+
+- [ ] `description:` field is present and domain-specific (references anti-cheat / security / vulnerability assessment)
+- [ ] `allowed-tools:` list includes Read, Write, Edit, Bash, Glob, Grep
+- [ ] Model tier is Sonnet (default for specialists)
+- [ ] Agent definition does not claim authority over game logic design or server deployment
+
+---
+
+## Test Cases
+
+### Case 1: In-domain request — appropriate output
+**Input:** "Review the save data system for security issues."
+**Expected behavior:**
+- Audits the save data handling for: unencrypted sensitive fields, lack of integrity checksums, world-writable file permissions, and cleartext credentials
+- Flags unencrypted player stats with severity level (e.g., MEDIUM — enables offline stat manipulation)
+- Recommends: AES-256 encryption for sensitive fields, HMAC checksum for tamper detection
+- Produces a prioritized finding list (CRITICAL / HIGH / MEDIUM / LOW)
+- Does NOT change the save system code directly — produces findings for gameplay-programmer or engine-programmer to act on
+
+### Case 2: Out-of-domain request — redirects correctly
+**Input:** "Design the matchmaking algorithm to pair players by skill rating."
+**Expected behavior:**
+- Does NOT produce matchmaking algorithm design
+- Explicitly states that matchmaking design belongs to `network-programmer`
+- Redirects the request to `network-programmer`
+- May note it can review the matchmaking system for security vulnerabilities (e.g., rating manipulation) once the design is complete
+
+### Case 3: Critical vulnerability — SQL injection
+**Input:** (Hypothetical) "Review this server-side query handler: `query = 'SELECT * FROM users WHERE id=' + user_input`"
+**Expected behavior:**
+- Flags this as a CRITICAL vulnerability (SQL injection via unsanitized user input)
+- Provides immediate remediation: parameterized queries / prepared statements
+- Recommends a security review of all other query-construction code in the codebase
+- Escalates to `technical-director` given CRITICAL severity — does not leave the finding unescalated
+
+### Case 4: Security vs. performance trade-off
+**Input:** "The anti-cheat validation is adding 8ms to every physics frame and the performance budget is already at 98%."
+**Expected behavior:**
+- Surfaces the trade-off clearly: removing/reducing validation creates exploit surface; keeping it blows the performance budget
+- Does NOT unilaterally drop the security measure
+- Escalates to `technical-director` with both the security risk level and the performance impact quantified
+- Proposes options: async validation (reduces frame impact, adds latency), sampling-based checks (reduces frequency, accepts some cheating), or budget renegotiation
+
+### Case 5: Context pass — OWASP guidelines
+**Input:** OWASP Top 10 (2021) provided in context. Request: "Audit the game's login and account system."
+**Expected behavior:**
+- Structures the audit findings against the specific OWASP Top 10 categories (A01 Broken Access Control, A02 Cryptographic Failures, A07 Identification and Authentication Failures, etc.)
+- References specific control IDs from the provided list rather than generic advice
+- Flags each finding with the relevant OWASP category
+- Produces a compliance gap list: which controls are met, which are missing, which are partial
+
+---
+
+## Protocol Compliance
+
+- [ ] Stays within declared domain (anti-cheat, save security, network security, vulnerability assessment)
+- [ ] Redirects matchmaking / game logic requests to appropriate agents
+- [ ] Returns structured findings with severity classification (CRITICAL / HIGH / MEDIUM / LOW)
+- [ ] Does not implement fixes unilaterally — produces findings for the responsible programmer
+- [ ] Escalates CRITICAL findings to technical-director immediately
+- [ ] References specific standards (OWASP, GDPR, etc.) when provided in context
+
+---
+
+## Coverage Notes
+- Save data audit (Case 1) confirms the agent produces actionable, prioritized findings not generic advice
+- CRITICAL vulnerability escalation (Case 3) verifies the agent's severity classification and escalation path
+- Performance trade-off (Case 4) confirms the agent does not silently drop security measures to hit a budget