mirror of https://github.com/Donchitos/Claude-Code-Game-Studios.git synced 2026-10-16 01:37:05 +00:00

Files

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

4.7 KiB

Raw Permalink Blame History

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

Read catalog.yaml to get the skill's spec: path and category:
Read the skill at .claude/skills/[name]/SKILL.md
Read the spec at the spec: path
Evaluate assertions case by case
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.

4.7 KiB Raw Permalink Blame History