关于 game-improvement-loop
game-improvement-loop 是通过证据和试玩迭代改进游戏的技能，面向使用 Agent 开展游戏开发的团队。它要求先确认改进方向，再实施、按时试玩并记录玩家体验证据。
主要功能
- 01编写规格或代码前先确认方向
- 02按顺序开展改进周期
- 03根据交付证据选择试玩目标
- 04记录证据与周期结论
- 05提供子 Agent 协作指引
适用场景
- 01改进游戏面向玩家的行为
- 02在目标运行环境中测试改动
- 03将试玩发现带入下一周期
安装
复制下面的命令，在终端中运行。
$
npx skills add https:/安装后在 Claude Code 中输入/game-improvement-loop确认已加载。
详细介绍
游戏改进循环
通过简短的证据循环改进这款游戏。以玩家体验为核心，并根据游戏类型、平台、操控方式和设计承诺调整循环。
默认设置
- 循环次数：3 次，除非用户另有说明。
- 游玩测试：每个循环 30 分钟，除非用户另有说明。
- 日志：
.scratch/game-improvement-loop/<YYYY-MM-DD>-<goal-slug>/cycle-N.md。
除非用户同意，否则不要缩短用户要求的或默认的游玩测试。如果无法进行完整的游玩测试，请将该循环标记为未完成。
启动关卡
编写 PRD 或代码之前：
- 阅读与玩家可见行为相关的本地规则、文档、过往游玩测试、工单/PRD 和代码路径。
- 仅在有助于实现用户要求的目标时，才研究外部参考资料。
- 返回简洁的方向概要：
- 对玩家的承诺
- 要改进的行为
- 建议方向及主要备选方案
- 可能涉及的数据/状态需求
- 主要玩家角色
- 可观察的游玩测试迹象
- 循环次数和游玩测试时长
- 等待用户确认。
获得确认后，除非遇到阻碍或方向变得不可行，否则继续完成所有循环。
循环
- 明确假设：承诺、设计押注、可观察迹象。
- 调研：代码、文档、过往游玩测试、有用的外部来源。
- 使用
to-spec编写规格：假设、玩家角色、体验、非目标、验收标准、测试/游玩测试计划。 - 实施本轮循环。如果规格已指向可直接实施的工单，则使用
handle-tickets，并记录其 PR、分支、检查项、阻碍因素和 Codex 结果。否则使用implement开展聚焦于工单规模的工作，然后在存在 PR 时运行review-fix和codex-pr-review。保持切片纵向完整且可游玩。 - 根据交付证据选择游玩测试目标：交付工作树、预览 URL、已合并的默认分支，或因等待合并而受阻的目标。在目标运行环境中按要求时长进行游玩测试。条件允许时，优先使用干净会话、有代表性的视口/设备，以及现有自动化测试框架。
- 记录证据：方法、运行环境/构建版本/URL、视口/设备、会话 ID、开始/结束时间、时长、输入数量、对话记录/日志/截图路径、状态污染风险，以及至少 5 个与玩家体验相关的时刻。
- 给出判定：
validated、mixed、invalidated或incomplete。 - 将影响最大的不足作为下一轮循环的种子。
子 Agent
仅当子 Agent 能显著助力工作，且任务可以清晰拆分时才使用。循环需按顺序进行，因为每轮循环都会为下一轮提供种子。
在单个循环内并行处理互相独立的工作：代码库调研、设计参考资料、测试/工具检查、素材审查，或涉及互不重叠文件的有限范围实施工作。
工作者任务说明必须包含方向、循环编号、玩家角色、日志路径、工单/PRD 预期、可能涉及的模块、验证命令、游玩测试时长、工作树有未提交更改时的警告，以及必要的交接内容。
循环日志
# Cycle N: <goal>
## Approved Direction
## Persona
## Hypothesis
## Research
## PRD
## Implementation
## Verification
## Playtest Evidence
## Observations
## Verdict
## Next Seed
## Blockers Or Fallbacks
结束
总结各循环、PRD/工单、PR、工作树或预览目标、检查项、游玩测试证据、判定、阻碍因素，以及下一项最佳改进。若有任何循环未完成，请明确说明。
评论
支持 Markdown