添加 claude code game studios 到项目
This commit is contained in:
panw
178
CCGS Skill Testing Framework/skills/utility/playtest-report.md
Normal file
178
CCGS Skill Testing Framework/skills/utility/playtest-report.md
Normal file
@@ -0,0 +1,178 @@
|
||||
# Skill Test Spec: /playtest-report
|
||||
|
||||
## 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/`.
|
||||
|
||||
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.
|
||||
|
||||
---
|
||||
|
||||
## Static Assertions (Structural)
|
||||
|
||||
Verified automatically by `/skill-test static` — 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)
|
||||
|
||||
---
|
||||
|
||||
## Director Gate Checks
|
||||
|
||||
None. `/playtest-report` is a documentation utility. The CD-PLAYTEST gate is a
|
||||
separate invocation and not part of this skill.
|
||||
|
||||
---
|
||||
|
||||
## Test Cases
|
||||
|
||||
### Case 1: Happy Path — User provides playtest notes, structured report produced
|
||||
|
||||
**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)
|
||||
|
||||
**Input:** `/playtest-report` (user pastes session notes)
|
||||
|
||||
**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
|
||||
|
||||
**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
|
||||
- [ ] Verdict is COMPLETE
|
||||
|
||||
---
|
||||
|
||||
### Case 2: Empty Input — Guided prompting through each section
|
||||
|
||||
**Fixture:**
|
||||
- No notes provided by user at invocation
|
||||
|
||||
**Input:** `/playtest-report`
|
||||
|
||||
**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
|
||||
|
||||
**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
|
||||
- [ ] Verdict is COMPLETE
|
||||
|
||||
---
|
||||
|
||||
### Case 4: Bug Matches Existing Report — Links to existing file
|
||||
|
||||
**Fixture:**
|
||||
- `production/bugs/bug-2026-03-30-player-stuck-ledge.md` exists
|
||||
- User's playtest notes describe "player gets stuck on ledges near walls"
|
||||
|
||||
**Input:** `/playtest-report`
|
||||
|
||||
**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
|
||||
|
||||
**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
|
||||
|
||||
---
|
||||
|
||||
### Case 5: Director Gate Check — No gate; CD-PLAYTEST is a separate invocation
|
||||
|
||||
**Fixture:**
|
||||
- Playtest notes provided
|
||||
|
||||
**Input:** `/playtest-report`
|
||||
|
||||
**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
|
||||
|
||||
**Assertions:**
|
||||
- [ ] No director gate is invoked
|
||||
- [ ] No CD-PLAYTEST gate skip message appears
|
||||
- [ ] Verdict is COMPLETE without any gate check
|
||||
|
||||
---
|
||||
|
||||
## 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
|
||||
|
||||
---
|
||||
|
||||
## 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.
|
||||
Reference in New Issue
Block a user