ksh999000/Claude-Code-Game-Studios
1
0
Fork 0
mirror of https://github.com/Donchitos/Claude-Code-Game-Studios.git synced 2026-10-16 10:17:06 +00:00
Code Issues Packages Projects Releases Wiki Activity

Release 1.1.2 — the default path works end to end

Browse Source 
Fix release for 1.1.1: the minimal path end to end, engine commands that
run on Godot, Unity and Unreal, hook warnings you can see, and verdicts
that say when they could not check. Details in CHANGELOG.md; upgrade
steps in UPGRADING.md (v1.1.1 → v1.1.2).

Fixes #67
Fixes #131

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WuJn2FdynEybfL5KC697nJ
This commit is contained in:
Donchitos
2026-09-29 21:32:19 +10:00
co-authored by Claude Opus 5.5
parent 7ed2c3e9c4
commit b21fa0f7f2
383 changed files with 22888 additions and 10618 deletions
Download Patch File Download Diff File Expand all files Collapse all files
CCGS Skill Testing Framework/skills/utility/playtest-report.md
+132 -104
View File
@@ -2,177 +2,205 @@
## Skill Summary
`/playtest-report` generates a structured playtest report from session notes or
user input. The report is organized into four sections: Feel/Accessibility,
Bugs Observed, Design Feedback, and Next Steps. When multiple testers participated,
the skill aggregates feedback and distinguishes majority opinions from minority
ones. The skill links to existing bug reports when a reported bug matches a file
in `production/bugs/`.
`/playtest-report` has two modes. `new` outputs a blank playtest report template
and stops with Verdict COMPLETE, saving nothing;
`analyze [path]` reads raw notes from a file, cross-references the design
documents, fills the template with structured findings and flags observations
that conflict with design intent. Defects (crashes, framerate drops) go in the
Bugs Encountered table, not under Gameplay Flow → Pain points. The template has these sections: Session Info,
Test Focus, First Impressions, Gameplay Flow (what worked, pain points,
confusion, delight), Bugs Encountered, Feature-Specific Feedback, Quantitative
Data, Overall Assessment, and Top 3 Priorities.
Reports are written to `production/qa/playtest-[date].md` after a "May I write"
ask. No director gates apply here — the CD-PLAYTEST director gate (if needed) is
a separate invocation. The verdict is COMPLETE when the report is written.
Findings are sorted into four buckets and routed: design changes to
`/propagate-design-change [path]`, balance adjustments to `/balance-check
[system]`, bugs to `/bug-report`, polish items to the `production/` backlog. In
`full` review mode the skill spawns `creative-director` for gate **CD-PLAYTEST**;
in `lean` and `solo` it skips the gate with a note. It then asks "May I write
this playtest report to `production/qa/playtests/playtest-[date]-[tester].md`?".
Verdict is **COMPLETE**.
---
## Static Assertions (Structural)
Verified automatically by `/skill-test static` — no fixture needed.
Checked against the SKILL.md by `/skill-test spec` — no fixture needed.
- [ ] Has required frontmatter fields: `name`, `description`, `argument-hint`, `user-invocable`, `allowed-tools`
- [ ] Has ≥2 phase headings
- [ ] Contains verdict keyword: COMPLETE
- [ ] Contains "May I write" collaborative protocol language before writing the report
- [ ] Has a next-step handoff (e.g., `/bug-report` for new issues found, `/design-review` for feedback)
- [ ] Has a next-step handoff (`/design-review` after design changes, `/bug-triage` after bug fixes)
---
## Director Gate Checks
None. `/playtest-report` is a documentation utility. The CD-PLAYTEST gate is a
separate invocation and not part of this skill.
- **Full mode**: CD-PLAYTEST — `creative-director` reviews the report against the
game pillars and core fantasy (APPROVE / CONCERNS / REJECT, or NOT ASSESSED
when it lacked an input), after findings are categorised and before the report
is saved
- **Lean mode**: CD-PLAYTEST skipped (not a PHASE-GATE); note
"CD-PLAYTEST skipped — Lean mode."
- **Solo mode**: CD-PLAYTEST skipped; note "CD-PLAYTEST skipped — Solo mode."
---
## Test Cases
### Case 1: Happy Path — User provides playtest notes, structured report produced
### Case 1: Happy Path — Analyze Notes, Findings Routed by Bucket
**Fixture:**
- User provides typed playtest notes from a single session
- Notes cover: game feel, one bug (framerate drop), and a design concern
(tutorial too long)
- `production/bugs/` exists but is empty (bug not yet reported)
- `production/qa/notes/session-01.md` holds one tester's notes: "framerate
drops every time the forest area loads", "I could not work out how to open
the first door", and "the second boss hits far too hard"
- `design/gdd/` holds the tutorial and combat GDDs; the tutorial GDD says the
first door teaches the interact key
- Review mode: `solo`
**Input:** `/playtest-report` (user pastes session notes)
**Input:** `/playtest-report analyze production/qa/notes/session-01.md`
**Expected behavior:**
1. Skill reads the provided notes and structures them into the 4-section template
2. Feel/Accessibility: extracts feel observations
3. Bugs: notes the framerate drop with available repro details
4. Design Feedback: notes the tutorial length concern
5. Next Steps: suggests `/bug-report` for the framerate issue and `/design-review`
for the tutorial feedback
6. Skill asks "May I write to `production/qa/playtest-2026-04-06.md`?"
7. Report is written on approval; verdict is COMPLETE
1. Skill reads the notes and cross-references the design documents
2. Skill fills the template; the framerate drop goes in the Bugs Encountered table
3. Phase 3 presents findings in four buckets: the door confusion as a design
change, the boss damage as a balance adjustment, the framerate drop as a bug
4. Routing: `/propagate-design-change` on the tutorial GDD, `/balance-check` for
combat, `/bug-report` for the framerate drop
5. Skill notes "CD-PLAYTEST skipped — Solo mode." and asks "May I write this
playtest report to `production/qa/playtests/playtest-[date]-[tester].md`?"
6. On approval the file is written; verdict is COMPLETE
**Assertions:**
- [ ] All 4 sections are present in the report
- [ ] Bug is listed in the Bugs section (not the Design Feedback section)
- [ ] Next Steps are appropriate (bug report for crash, design review for feedback)
- [ ] "May I write" is asked before writing
- [ ] The framerate drop appears in the Bugs Encountered table, not under Gameplay Flow
- [ ] Findings are presented in the four buckets (design, balance, bug, polish)
- [ ] Each bucket is routed to its named skill (`/propagate-design-change`, `/balance-check`, `/bug-report`)
- [ ] "May I write" names `production/qa/playtests/playtest-[date]-[tester].md` before writing
- [ ] Verdict is COMPLETE
---
### Case 2: Empty Input — Guided prompting through each section
### Case 2: New Mode — Blank Template Output
**Fixture:**
- No notes provided by user at invocation
- Any project state
**Input:** `/playtest-report`
**Input:** `/playtest-report new`
**Expected behavior:**
1. Skill detects empty input
2. Skill prompts through each section:
a. "Describe the overall feel and any accessibility observations"
b. "Were any bugs observed? Describe them"
c. "What design feedback did testers provide?"
3. User answers each prompt
4. Skill compiles report from answers and asks "May I write"
5. Report written on approval; verdict is COMPLETE
1. Skill selects `new` mode
2. Skill outputs the blank template with every section heading and its
bracketed placeholders unfilled
3. No notes file is read and no findings are invented
4. The mode ends after the template: no routing, no director gate, no save
ask, and the verdict is COMPLETE — blank template output; nothing saved
**Assertions:**
- [ ] At least 3 guiding questions are asked (one per main section)
- [ ] Report is not created until all sections have input (or user explicitly skips one)
- [ ] Verdict is COMPLETE after file is written
---
### Case 3: Multiple Testers — Aggregated feedback with majority/minority notes
**Fixture:**
- User provides notes from 3 testers
- 2/3 testers found the controls "intuitive"
- 1/3 tester found the UI font too small
- All 3 noted the same bug (player stuck on ledge)
**Input:** `/playtest-report` (3-tester session)
**Expected behavior:**
1. Skill identifies 3 distinct tester perspectives in the input
2. Control intuitiveness → noted as "Majority (2/3): controls intuitive"
3. Font size → noted as "Minority (1/3): UI font size concern"
4. Stuck-on-ledge bug → noted as "All testers: player stuck on ledge (confirmed)"
5. Skill generates aggregated report with majority/minority labels
6. Report written after "May I write" approval; verdict is COMPLETE
**Assertions:**
- [ ] Majority opinion (2/3) is labeled as majority
- [ ] Minority opinion (1/3) is labeled as minority
- [ ] Unanimously reported bug is noted as confirmed by all testers
- [ ] Output contains the headings Session Info, Test Focus, First Impressions, Gameplay Flow, Bugs Encountered, Feature-Specific Feedback, Quantitative Data, Overall Assessment and Top 3 Priorities
- [ ] Placeholders (e.g. `[Date]`, `[Name/ID]`) are left unfilled
- [ ] No notes file is read and no findings are fabricated
- [ ] No "May I write" ask and no file written
- [ ] Verdict is COMPLETE
---
### Case 4: Bug Matches Existing Report — Links to existing file
### Case 3: Observation Conflicts With Design Intent
**Fixture:**
- `production/bugs/bug-2026-03-30-player-stuck-ledge.md` exists
- User's playtest notes describe "player gets stuck on ledges near walls"
- `design/gdd/crafting.md` states crafting is a core loop players engage with
every session
- `production/qa/notes/session-02.md` records that the tester never opened the
crafting menu in 40 minutes
- Review mode: `solo`
**Input:** `/playtest-report`
**Input:** `/playtest-report analyze production/qa/notes/session-02.md`
**Expected behavior:**
1. Skill structures the report and identifies the stuck-on-ledge bug
2. Skill scans `production/bugs/` and finds `bug-2026-03-30-player-stuck-ledge.md`
3. In the Bugs section, the report includes: "See existing report:
production/bugs/bug-2026-03-30-player-stuck-ledge.md"
4. Skill does NOT suggest creating a new bug report for this issue
5. Report written; verdict is COMPLETE
1. Skill reads the notes and cross-references `design/gdd/crafting.md`
2. Skill flags the observation as conflicting with design intent
3. Phase 3 puts it in the "Design changes needed" bucket
4. Routing names `/propagate-design-change` on `design/gdd/crafting.md`
5. Report saved after the "May I write" ask; verdict COMPLETE
**Assertions:**
- [ ] Existing bug report is found and linked in the playtest report
- [ ] `/bug-report` is NOT suggested for the already-reported issue
- [ ] Cross-reference to existing file appears in the Bugs section
- [ ] Verdict is COMPLETE
- [ ] The crafting observation is explicitly flagged as conflicting with the GDD's intent
- [ ] It is categorised as a design change, not a polish item
- [ ] `/propagate-design-change` is suggested on the affected GDD
- [ ] Verdict is COMPLETE after the write
---
### Case 5: Director Gate Check — No gate; CD-PLAYTEST is a separate invocation
### Case 4: Edge Case — Full Review Mode With No Pillars Available
**Fixture:**
- Playtest notes provided
- Review mode: `full`
- Neither `design/gdd/game-concept.md` nor `design/game-brief.md` exists
- `production/qa/notes/session-03.md` holds playtest notes
**Input:** `/playtest-report`
**Input:** `/playtest-report analyze production/qa/notes/session-03.md`
**Expected behavior:**
1. Skill generates and writes the playtest report
2. No director agents are spawned (CD-PLAYTEST is not invoked here)
3. No gate IDs appear in output
1. Skill structures and categorises the findings
2. Skill spawns `creative-director` for CD-PLAYTEST with the report content and
the hypothesis being tested
3. Because neither pillars source exists, the prompt states "No pillars
available — assess against the hypothesis alone." rather than omitting pillars
4. The director's assessment is presented before the save ask
**Assertions:**
- [ ] No director gate is invoked
- [ ] No CD-PLAYTEST gate skip message appears
- [ ] Verdict is COMPLETE without any gate check
- [ ] CD-PLAYTEST is spawned (review mode is `full`)
- [ ] The gate prompt says no pillars are available instead of passing none silently
- [ ] Pillars are not invented by the skill
- [ ] The assessment is shown before "May I write"
---
### Case 5: Director Gate — CD-PLAYTEST by Review Mode
**Fixture:**
- `design/gdd/game-concept.md` exists with pillars
- `production/qa/notes/session-04.md` holds playtest notes
- Run three times: `--review full`, `--review lean`, `--review solo`
- In the full run, `creative-director` returns CONCERNS
**Input:** `/playtest-report analyze production/qa/notes/session-04.md --review [mode]`
**Expected behavior:**
1. Full: after Phase 3 categorisation, `creative-director` is spawned for
CD-PLAYTEST with the report content, pillars from `game-concept.md` and the
hypothesis; its CONCERNS assessment is presented and a
`## Creative Director Assessment` section is added to the report
2. Lean: no director spawned; note "CD-PLAYTEST skipped — Lean mode."
3. Solo: no director spawned; note "CD-PLAYTEST skipped — Solo mode."
4. All three runs then ask "May I write" and end with verdict COMPLETE
**Assertions:**
- [ ] In full mode, CD-PLAYTEST spawns `creative-director` before the report is saved
- [ ] On CONCERNS, the report gains a `## Creative Director Assessment` section with the verdict and feedback
- [ ] In lean mode, the skip note names CD-PLAYTEST and Lean mode
- [ ] In solo mode, the skip note names CD-PLAYTEST and Solo mode
- [ ] No other director gate is spawned in any mode
---
## Protocol Compliance
- [ ] Structures output into all 4 sections (Feel, Bugs, Design Feedback, Next Steps)
- [ ] Labels majority vs. minority opinions when multiple testers are involved
- [ ] Cross-references existing bug reports when bugs match
- [ ] Asks "May I write to `production/qa/playtest-[date].md`?" before writing
- [ ] Verdict is COMPLETE when report is written
- [ ] `analyze` reads the notes file and cross-references design documents before filling the template
- [ ] Findings are categorised into design / balance / bug / polish and routed to the named follow-up
- [ ] Applies the review mode before spawning CD-PLAYTEST and prints the skip note when skipped
- [ ] Presents the director's assessment (full mode) before asking to save
- [ ] Asks "May I write this playtest report to `production/qa/playtests/playtest-[date]-[tester].md`?" before writing
- [ ] Ends with verdict COMPLETE and next steps (`/design-review`, `/bug-triage`)
---
## Coverage Notes
- The CD-PLAYTEST director gate (creative director reviews playtest insights
for design implications) is a separate invocation and is not tested here.
- Video recording or screenshot attachments are not tested; the report is a
text-only document.
- The case where a tester's identity is unknown (anonymous feedback) follows
the same aggregation pattern as Case 3 without tester labels.
- A REJECT verdict from CD-PLAYTEST follows the same path as CONCERNS (an
assessment section is added) and is not separately tested; APPROVE only adds
an approval note. NOT ASSESSED (the director lacked an input) adds the section
naming what was missing and is never read as an approval; not separately tested.
- At `modes.workflow: minimal`, where `design/game-brief.md` replaces
`game-concept.md`, the brief has no pillars: its one-sentence pitch and "Who
it's for / what they feel" line are passed in their place; not separately tested.
- Video or screenshot attachments are not tested; the report is text only.