179 lines
6.4 KiB
Markdown
179 lines
6.4 KiB
Markdown
# 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.
|