6.4 KiB
6.4 KiB
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-reportfor new issues found,/design-reviewfor 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:
- Skill reads the provided notes and structures them into the 4-section template
- Feel/Accessibility: extracts feel observations
- Bugs: notes the framerate drop with available repro details
- Design Feedback: notes the tutorial length concern
- Next Steps: suggests
/bug-reportfor the framerate issue and/design-reviewfor the tutorial feedback - Skill asks "May I write to
production/qa/playtest-2026-04-06.md?" - 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:
- Skill detects empty input
- 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?"
- User answers each prompt
- Skill compiles report from answers and asks "May I write"
- 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:
- Skill identifies 3 distinct tester perspectives in the input
- Control intuitiveness → noted as "Majority (2/3): controls intuitive"
- Font size → noted as "Minority (1/3): UI font size concern"
- Stuck-on-ledge bug → noted as "All testers: player stuck on ledge (confirmed)"
- Skill generates aggregated report with majority/minority labels
- 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.mdexists- User's playtest notes describe "player gets stuck on ledges near walls"
Input: /playtest-report
Expected behavior:
- Skill structures the report and identifies the stuck-on-ledge bug
- Skill scans
production/bugs/and findsbug-2026-03-30-player-stuck-ledge.md - In the Bugs section, the report includes: "See existing report: production/bugs/bug-2026-03-30-player-stuck-ledge.md"
- Skill does NOT suggest creating a new bug report for this issue
- Report written; verdict is COMPLETE
Assertions:
- Existing bug report is found and linked in the playtest report
/bug-reportis 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:
- Skill generates and writes the playtest report
- No director agents are spawned (CD-PLAYTEST is not invoked here)
- 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.