用途
phaser-feedback 用于把玩家反馈转化为已发布的修复。反馈通常来自不懂代码的玩家，以自然语言描述体验，例如“跳跃感觉飘，有时会直接穿过平台，Boss 根本打不过，商店坏了”。这些句子包含不同类型的问题，如果一视同仁地处理，修复会话结束时玩家真正的抱怨可能仍未被触及。该技能提供一套从录入到验证的完整循环，帮助开发者正确分类、复现、修复并回复反馈。
主要能力
该技能的核心流程为：录入（intake）→ 分类（triage）→ 按根因分组（group by root cause）→ 复现为失败场景（reproduce）→ 修复（fix）→ 验证（verify）→ 回复并保留场景（report back）。其中“先复现再修复”是关键步骤：一个因玩家描述的原因而失败的测试场景，证明你理解了玩家；没有它，你只是在用代码模式匹配文字，最常见的结果是修了一个没人抱怨的问题。
分类阶段将反馈分为四类：
- 缺陷（Defect）：游戏做了不该做的事，需要失败场景然后修复，由开发者决定。
- 调优（Tuning）：代码按设定运行，但数值感觉不对，需要数值目标然后改值，由用户决定。
- 设计（Design）：游戏按设计运行，但该设计不被接受，需要修改 GDD，由用户决定。
- 不可操作（Unactionable）：需要向报告者追问具体问题，由报告者决定。
分组阶段将可能共享同一根因的报告合并，避免逐个打补丁。复现阶段把玩家文字翻译成机器可检查的场景，并强调场景必须先失败。运行场景时支持 --repeat 10 来区分间歇性 bug、RNG 相关 bug 和时序问题，支持 --seed 42 判断是否依赖 RNG 路径，支持 --device iphone / --device android 处理平台相关报告，支持 --heap 处理性能或内存报告。
修复阶段要求先调查、解释原因再动手；同一方法失败两次后应转向其他方案；修复分组后的根因而非每个症状。验证阶段要求复现场景通过（间歇性 bug 需重复运行足够次数）且其他场景未被破坏，并运行类型检查、构建模式和全部场景。回复阶段要求用报告者的语言说明修了什么、改了什么需要确认、还需要他们提供什么。最后将复现场景提交为永久回归测试。
使用方式
该技能通过场景文件运行。示例场景文件 playtest/repro-fall-through-platform.mjs 定义了一系列动作，包括设置报告中的情况、等待玩家落到平台上、断言玩家仍在平台上方。运行命令为：
node "${CLAUDE_PLUGIN_ROOT}/skills/phaser-playtest/scripts/playtest.mjs"
--project . --scenario playtest/repro-fall-through-platform.mjs
对于“有时”类频率声明，使用 --repeat 10：
node ".../playtest.mjs" --project . --scenario playtest/repro.mjs --repeat 10
验证时运行：
node ".../playtest.mjs" --project . --scenario playtest/repro-fall-through-platform.mjs --repeat 10 npx tsc --noEmit node ".../playtest.mjs" --project . --mode build for f in playtest/*.mjs; do node ".../playtest.mjs" --project . --scenario "$f"; done
适用场景
适用于 Phaser 4 游戏开发中处理玩家反馈、测试者笔记、bug 报告、Discord 或 Reddit 评论、itch.io 评论、App Store 评论等。特别适合需要区分缺陷、调优、设计、不可操作四类反馈，以及需要将模糊描述转化为可复现测试场景的情况。也适用于处理间歇性 bug、平台相关 bug、性能报告和回归测试。
限制
该技能依赖 phaser-playtest 提供的测试框架和场景参考，以及游戏本身需要具备一定的可观测性。对于口味问题（如难度感受、美术可读性、音频混音、“是否好玩”）无法用无头浏览器解决，必须标记为需要人工判断，不能编造数值目标。对于不可操作的反馈，需要向报告者追问具体信息。该技能不提供收费、价格、平台或效果方面的信息。