Files
Claude-Code-Game-Studios/CCGS Skill Testing Framework/CLAUDE.md
T
DonchitosandClaude Opus 5 d05699707f Release 1.1.0 — one config file, and a process weight you choose
`project.yaml` at the repo root is now the single source of truth for a
project's configuration, replacing `production/stage.txt`,
`production/review-mode.txt` and `.claude/docs/technical-preferences.md` (all
three still read as a fallback; nothing is force-deleted).

**`modes.rigor` — one question instead of six.** `minimal`, `standard` or
`full` fronts six knobs: `modes.workflow`, `docs.density`, `qa.level`,
`modes.story_granularity`, `modes.review_mode` and `team.size`. It defaults to
`minimal`, which is a change from 1.0's behaviour: the heavier tier was
measured costing several times more to reach working code without producing a
better result, and returning nothing when a fresh developer inherited the
project. Pin `modes.rigor: standard` to keep 1.0's process level.

Also in this release:

- `/settings` to view or change any setting, and `project.local.yaml` for
  per-developer preferences that should not be committed.
- `system_overrides` to hold one system to a higher standard than the rest of
  the project, and `testing.strict` to set per test type whether missing
  evidence blocks a story or warns.
- A story that changes anything the player sees is not closed until the game
  has been launched, observed, and a screenshot retained in
  `production/qa/evidence/`. A parse check is not a run. This holds at every
  rigor level, including `minimal`, where automated tests are waived but the
  look is not.
- The code root is engine-specific and enforced as such: Godot `src/`, Unity
  `Assets/`, Unreal `Source/<Module>/`. Two of the three will not build a
  project laid out any other way.
- Migration tooling for existing projects: `.claude/scripts/migrate-v1-config.sh`
  converts a 1.0 layout, non-destructively by default, with a report to review
  before `--finalize` deletes anything.
- Ask-before-write holds regardless of personal automation settings.

Upgrading from 1.0 or earlier: see UPGRADING.md. Full list of changes:
CHANGELOG.md.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016xvzG3i7pWQg4LjyDwWMXd
2026-09-23 12:25:11 +10:00

95 lines
4.7 KiB
Markdown

# CCGS Skill Testing Framework — Claude Instructions
This folder is the quality assurance layer for the Claude Code Game Studios skill/agent
framework. It is self-contained and separate from any game project.
## Key files
| File | Purpose |
|------|---------|
| `catalog.yaml` | Master registry for all 74 skills and 49 agents. Contains category, spec path, and last-test tracking fields. Always read this first when running any test command. |
| `quality-rubric.md` | Category-specific pass/fail metrics. Read the matching `###` section for the skill's category when running `/skill-test category`. |
| `skills/[category]/[name].md` | Behavioral spec for a skill — 5 test cases + protocol compliance assertions. |
| `agents/[tier]/[name].md` | Behavioral spec for an agent — 5 test cases + protocol compliance assertions. |
| `templates/skill-test-spec.md` | Template for writing new skill spec files. |
| `templates/agent-test-spec.md` | Template for writing new agent spec files. |
| `results/` | Written by `/skill-test spec` when results are saved. Gitignored. |
## Path conventions
- Skill specs: `CCGS Skill Testing Framework/skills/[category]/[name].md`
- Agent specs: `CCGS Skill Testing Framework/agents/[tier]/[name].md`
- Catalog: `CCGS Skill Testing Framework/catalog.yaml`
- Rubric: `CCGS Skill Testing Framework/quality-rubric.md`
The `spec:` field in `catalog.yaml` is the authoritative path for each skill/agent spec.
Always read it rather than guessing the path.
## Skill categories
```
gate → gate-check
review → design-review, architecture-review, review-all-gdds
authoring → design-system, quick-design, architecture-decision, art-bible,
create-architecture, ux-design, ux-review
readiness → story-readiness, story-done
pipeline → create-epics, create-stories, dev-story, create-control-manifest,
propagate-design-change, map-systems, vertical-slice
analysis → consistency-check, balance-check, content-audit, code-review,
tech-debt, scope-check, estimate, perf-profile, asset-audit,
security-audit, test-evidence-review, test-flakiness
team → team-combat, team-narrative, team-audio, team-level, team-ui,
team-qa, team-release, team-polish, team-live-ops
sprint → sprint-plan, sprint-status, milestone-review, retrospective,
changelog, patch-notes
utility → all remaining skills
```
## Agent tiers
```
directors → creative-director, technical-director, producer, art-director
leads → lead-programmer, narrative-director, audio-director, game-designer,
systems-designer, level-designer, qa-lead
specialists → gameplay-programmer, engine-programmer, network-programmer,
ai-programmer, tools-programmer, ui-programmer, ux-designer,
technical-artist, sound-designer, performance-analyst, prototyper,
writer, world-builder
engine/godot → godot-specialist, godot-gdscript-specialist, godot-csharp-specialist,
godot-shader-specialist, godot-gdextension-specialist
engine/unity → unity-specialist, unity-ui-specialist, unity-shader-specialist,
unity-dots-specialist, unity-addressables-specialist
engine/unreal → unreal-specialist, ue-gas-specialist, ue-replication-specialist,
ue-umg-specialist, ue-blueprint-specialist
operations → devops-engineer, release-manager, live-ops-designer,
community-manager, analytics-engineer, economy-designer,
localization-lead
qa → qa-tester, security-engineer, accessibility-specialist
```
## Workflow for testing a skill
1. Read `catalog.yaml` to get the skill's `spec:` path and `category:`
2. Read the skill at `.claude/skills/[name]/SKILL.md`
3. Read the spec at the `spec:` path
4. Evaluate assertions case by case
5. Offer to write results to `results/` and update `catalog.yaml`
## Workflow for improving a skill
Use `/skill-improve [name]`. It handles the full loop:
test → diagnose → propose fix → rewrite → retest → keep or revert.
## Spec validity note
Specs in this folder describe **current behavior**, not ideal behavior. They were
written by reading the skills, so they may encode bugs. When a skill misbehaves in
practice, correct the skill first, then update the spec to match the fixed behavior.
Treat spec failures as "this needs investigation," not "the skill is definitively wrong."
## This folder is deletable
Nothing in `.claude/` imports from here. Deleting this folder has no effect on the
CCGS skills or agents themselves. `/skill-test` and `/skill-improve` will report that
`catalog.yaml` is missing and guide the user to initialize it.