playtest-report

!bash "${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh" resolve_config --keys review_mode,automation

已在上方解析——按原样使用；本次运行中，--review 会覆盖 review_mode。未阻止 → 使用 .claude/docs/config-resolution.md 中的默认值。

Playtest 报告

阶段 1：解析参数

完整检查模式请参见 .claude/docs/director-gates.md。各项门禁的定义位于 .claude/docs/director-gates/[gate-id].md——生成的 Agent 会读取自己的门禁文件；父会话不要读取该文件。

每次调用 AskUserQuestion 都遵循 .claude/docs/automation-modes.md （协作模式始终提问 · 引导模式仅对重大事项提问 · 自主模式记录并继续； automation_always_ask 类别始终会提示）。

确定模式：

• new → 生成空白 Playtest 报告模板。此模式在阶段 2A 后结束：空白模板无需路由、审核或保存。
• analyze [path] → 读取原始笔记，并填写模板，整理出结构化发现
• 无参数 → 通过 AskUserQuestion 提问：[A] 新建空白模板 / [B] 分析笔记——我会提供路径

---

阶段 2A：新建模板模式

生成此模板并输出给用户：

# 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]

在 new 模式下，到此为止，并显示：结论：完成——已输出空白模板；未保存任何内容。

---

阶段 2B：分析模式

读取指定路径下的原始笔记。与现有设计文档交叉核对，逐节阅读：使用 Grep 工具查找所需标题（模式 ^#，内容模式），再通过 offset 和 limit 读取对应范围。使用结构化发现填写上方模板。标记任何与设计意图冲突的 Playtest 观察结果。

描述缺陷的观察结果——例如崩溃、帧率下降、软锁，或明显导致游戏无法正常运行而非游玩体验不佳的问题——应放入 遇到的 Bug 表格，而不是放在「游戏流程 → 痛点」下，并在阶段 3 作为 Bug 路由。痛点指的是游戏玩起来的感受。

---

阶段 3：行动路由

将所有发现分为四类：

• 需要设计变更——趣味性问题、玩家困惑、机制失效、与 GDD 预期体验相冲突的观察结果
• 平衡性调整——数值感觉不对，难度过于陡峭或过于平缓
• Bug 报告——可复现的明确实现缺陷
• 润色事项——不会阻碍进度，但会带来阻碍或影响体验感的问题，可留待后续处理

展示分类清单，然后进行路由：

• 设计变更：“对受影响的设计文档运行 /propagate-design-change [path]，在进行更改前查找下游影响。”
• 平衡性调整：“运行 /balance-check [system]，在调整数值前核查整体平衡情况。”
• Bug：“使用 /bug-report 正式跟踪这些问题。”
• 润色事项：“团队进入相应阶段后，将其加入 production/ 中的润色待办列表。”

---

Phase 3b：创意总监玩家体验评审

评审模式检查——在启动 CD-PLAYTEST 前应用：

• solo → 跳过。备注：“已跳过 CD-PLAYTEST——Solo 模式。”继续进入 Phase 4（保存报告）。
• lean → 跳过（不是 PHASE-GATE）。备注：“已跳过 CD-PLAYTEST——Lean 模式。”继续进入 Phase 4（保存报告）。
• full → 正常启动。

对发现的问题分类后，使用 Agent 启动 creative-director，并应用门禁 CD-PLAYTEST（.claude/docs/director-gates/cd-playtest.md）。

传入：结构化报告内容、游戏支柱和核心幻想（来自 design/gdd/game-concept.md），以及正在测试的具体假设。如果 game-concept.md 不存在——在 minimal 模式下这是预期情况，此时由 design/game-brief.md 替代——则简报中没有支柱：改为传入简报的一句话简介和“适合人群／他们的感受”这一行，并说明它们代替支柱。如果这两个文档都不存在，请在提示词中说明： “没有可用的支柱——仅根据假设进行评估。” 如果没有告知门禁支柱信息，创意总监就会自行编造。

保存报告前，先展示创意总监的评估。如果结果为 CONCERNS 或 REJECT，在报告中添加 ## Creative Director Assessment 章节，记录裁定和反馈。如果结果为 APPROVE，在报告中注明已批准。如果结果为 NOT ASSESSED（创意总监缺少某项输入——.claude/docs/director-gates.md），添加相同章节并说明缺少什么；这不代表批准。

---

Phase 4：保存报告

询问：“我可以将这份试玩报告写入 production/qa/playtests/playtest-[date]-[tester].md 吗？”

如果可以，则写入文件；如有需要，创建目录。

---

Phase 5：后续步骤

裁定：COMPLETE——试玩报告已生成。

• 优先处理优先级最高的问题类别。
• 完成设计修改后：对更新后的 GDD 重新运行 /design-review。
• 修复错误后：重新运行 /bug-triage，以更新优先级。