`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
5.5 KiB
name, description, argument-hint, user-invocable, allowed-tools, model
| name | description | argument-hint | user-invocable | allowed-tools | model |
|---|---|---|---|---|---|
| playtest-report | Structured playtest report template, or turn existing playtest notes into structured feedback. | [new|analyze path-to-notes] [--review full|lean|solo] | true | Read, Glob, Grep, Write, Agent, AskUserQuestion | sonnet |
!source "${CLAUDE_PROJECT_DIR:-.}/.claude/hooks/yaml-helper.sh" 2>/dev/null && resolve_config --keys review_mode,automation
Phase 1: Parse Arguments
See .claude/docs/director-gates.md for the full check pattern. Individual gate definitions live in .claude/docs/director-gates/[gate-id].md — the spawned agent reads its own gate file; do not read it in the parent session.
Every AskUserQuestion call follows .claude/docs/automation-modes.md
(collaborative asks always · guided major-only · autonomous logs and proceeds;
automation_always_ask categories always prompt).
Determine the mode:
new→ generate a blank playtest report templateanalyze [path]→ read raw notes and fill in the template with structured findings
Phase 2A: New Template Mode
Generate this template and output it to the user:
# Playtest Report
## Session Info
- **Date**: [Date]
- **Build**: [Version/Commit]
- **Duration**: [Time played]
- **Tester**: [Name/ID]
- **Platform**: [PC/Console/Mobile]
- **Input Method**: [KB+M / Gamepad / Touch]
- **Session Type**: [First time / Returning / Targeted test]
## Test Focus
[What specific features or flows were being tested]
## First Impressions (First 5 minutes)
- **Understood the goal?** [Yes/No/Partially]
- **Understood the controls?** [Yes/No/Partially]
- **Emotional response**: [Engaged/Confused/Bored/Frustrated/Excited]
- **Notes**: [Observations]
## Gameplay Flow
### What worked well
- [Observation 1]
### Pain points
- [Issue 1 -- Severity: High/Medium/Low]
### Confusion points
- [Where the player was confused and why]
### Moments of delight
- [What surprised or pleased the player]
## Bugs Encountered
| # | Description | Severity | Reproducible |
|---|-------------|----------|-------------|
## Feature-Specific Feedback
### [Feature 1]
- **Understood purpose?** [Yes/No]
- **Found engaging?** [Yes/No]
- **Suggestions**: [Tester suggestions]
## Quantitative Data (if available)
- **Deaths**: [Count and locations]
- **Time per area**: [Breakdown]
- **Items used**: [What and when]
- **Features discovered vs missed**: [List]
## Overall Assessment
- **Would play again?** [Yes/No/Maybe]
- **Difficulty**: [Too Easy / Just Right / Too Hard]
- **Pacing**: [Too Slow / Good / Too Fast]
- **Session length preference**: [Shorter / Good / Longer]
## Top 3 Priorities from this session
1. [Most important finding]
2. [Second priority]
3. [Third priority]
Phase 2B: Analyze Mode
Read the raw notes at the provided path. Cross-reference with existing design documents. Fill in the template above with structured findings. Flag any playtest observations that conflict with design intent.
Phase 3: Action Routing
Categorize all findings into four buckets:
- Design changes needed — fun issues, player confusion, broken mechanics, observations that conflict with the GDD's intended experience
- Balance adjustments — numbers feel wrong, difficulty too spiked or too flat
- Bug reports — clear implementation defects that are reproducible
- Polish items — not blocking progress, but friction or feel issues for later
Present the categorized list, then route:
- Design changes: "Run
/propagate-design-change [path]on the affected design document to find downstream impacts before making changes." - Balance adjustments: "Run
/balance-check [system]to verify the full balance picture before tuning values." - Bugs: "Use
/bug-reportto formally track these." - Polish items: "Add to the polish backlog in
production/when the team reaches that phase."
Phase 3b: Creative Director Player Experience Review
Review mode check — apply before spawning CD-PLAYTEST:
solo→ skip. Note: "CD-PLAYTEST skipped — Solo mode." Proceed to Phase 4 (save the report).lean→ skip (not a PHASE-GATE). Note: "CD-PLAYTEST skipped — Lean mode." Proceed to Phase 4 (save the report).full→ spawn as normal.
After categorising findings, spawn creative-director via Agent using gate CD-PLAYTEST (.claude/docs/director-gates/cd-playtest.md).
Pass: the structured report content, game pillars and core fantasy (from
design/gdd/game-concept.md), the specific hypothesis being tested. If
game-concept.md does not exist — expected at minimal, where
design/game-brief.md replaces it — pass the brief's pillars instead, and if
neither exists say so in the prompt: "No pillars available — assess against
the hypothesis alone." A director gate handed silence about pillars will
invent them.
Present the creative director's assessment before saving the report. If CONCERNS or REJECT, add a ## Creative Director Assessment section to the report capturing the verdict and feedback. If APPROVE, note the approval in the report.
Phase 4: Save Report
Ask: "May I write this playtest report to production/qa/playtests/playtest-[date]-[tester].md?"
If yes, write the file, creating the directory if needed.
Phase 5: Next Steps
Verdict: COMPLETE — playtest report generated.
- Act on the highest-priority finding category first.
- After addressing design changes: re-run
/design-reviewon the updated GDD. - After fixing bugs: re-run
/bug-triageto update priorities.