mcpField
R
roblox-to-issues

roblox-to-issues

github.com/ashexplained开发3895 次安装17 周前更新
代码仓库

关于 roblox-to-issues

将 Roblox 开发计划拆分为可独立构建和试玩的小任务的 Skill。它围绕端到端玩家体验安排切片，经确认后发布到配置的跟踪器或路线图文件。

主要功能

  1. 01将计划拆分为纵向切片
  2. 02围绕核心循环安排切片
  3. 03定义 Studio 试玩检查
  4. 04跟踪依赖项与审批
  5. 05发布任务并更新 ROADMAP.md

适用场景

  1. 01将游戏计划转为可试玩里程碑
  2. 02在实施前梳理依赖关系
  3. 03将获批切片发布到跟踪器

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/ashexplained/roblox-skills --skill roblox-to-issues

安装后在 Claude Code 中输入/roblox-to-issues确认已加载。

详细介绍

Roblox → Issues（垂直切片）

将计划拆分成多个小 Issue，每个都能独立构建和进行游戏测试。这可以避免“一口气构建整个游戏，结果到处都只做了一半、问题百出”。

跟踪位置和标签词汇应已在 CLAUDE.md / docs/agents/ 中提供。如果没有，请运行 setup-roblox-skills。切片发布为 GitHub Issue（gh），或发布为 roadmap/<feature-slug>/slices/ 下的 Markdown 文件——具体取决于设置时的配置。无论哪种情况，都要保留 ROADMAP.md 作为便于人阅读的索引。

什么是 Roblox 垂直切片

曳光弹：一条尽可能精简的端到端路径，玩家能实际感知到它，并贯穿所涉及的每一层——客户端输入、服务器权威逻辑、远程通信、DataStore 和 UI，而不是只覆盖某一横向层。

  • 正确（垂直）：“玩家点击矿石，服务器发放 1 枚金币，HUD 显示新余额，重新加入后余额仍然保留。”涉及输入 + 远程通信 + 服务器 + 数据 + UI。可以游玩。
  • 错误（横向）：“构建完整的经济模块。”/“构建所有 UI。”直到全部完成前都无法游玩——这正是我们要避免的问题。
切片规则
  • 每个切片都交付一项范围精简但完整、面向玩家的能力。
  • 每个切片都能独立在 Studio 游戏测试中验证（这是验收标准）。
  • 多做精简的切片，少做臃肿的切片。如果某个切片无法单独进行游戏测试，就继续拆分。
  • 从第一个切片开始，有价值的状态（货币、物品栏、购买、奖励、进度）就必须由服务器掌控——绝不要先走信任客户端的捷径，再打算以后修复。
  • 第一个切片就是曳光弹：用最小的内容端到端证明核心循环（一项操作 → 一份奖励 → 一个清晰可见的下一步目标）。先完成它，再做其他内容。
切片类型
  • AFK — 无需人工判断即可构建和验证。优先选择这类切片。
  • HITL — 需要人工参与：设计审批、平衡性判断，或只有用户才能执行的 Studio 操作。UI 切片在存在已批准的 UI 设计稿之前都属于 HITL（参见 roblox-game-ux）；如果缺少 UI 设计，先创建设计审批切片，并将 UI 切片设为依赖它。

流程

1. 收集上下文

根据 PRD / 对话开展工作。如果用户提供了参考（Issue 编号、ROADMAP.md 行或文件路径），请完整阅读。如果需要查看当前 place 状态，请通过 roblox-studio-workflow 连接。使用游戏本身的术语。

2. 起草切片

排序时，应将核心循环曳光弹作为切片 1，然后逐步扩展能力（持久化 → 进度 → 社交 → 变现 → 润色）。每个后续切片都应构建在已经可以游玩的切片之上。

3. 向用户确认

以编号列表呈现拆分结果。对于每个切片，列出：

  • 标题 — 简短、面向玩家。
  • 类型 — AFK / HITL。
  • 依赖项 — 必须先发布哪些切片。
  • 游戏测试检查 — 在 Studio 中验证功能正常的具体操作。
  • 是否由服务器掌控？ — 是/否，以及保护的状态。

询问：颗粒度是否合适（太粗 / 太细）？依赖关系是否正确？是否应进一步拆分某些切片？HITL / AFK 分类是否正确？反复调整，直到用户批准。

4. 发布

将每个已批准的切片发布到配置的跟踪系统，并设置 needs-triage 标签 / 状态；先发布依赖项，方便引用真实 ID。按照此包的约定，在 ROADMAP.md 中将每个切片同步为复选框：[ ] 表示尚未开始，[~] 表示已构建并测试、但仍待审批，只有在完成构建 + 游戏测试 + 获得明确的人工批准后才标记为 [x]。

## 构建内容

描述此切片面向玩家的端到端行为。说明玩家做什么以及服务器做什么——不要按层逐一描述实现方式。

涉及层

  • 客户端：...
  • 服务器（权威）：...
  • 远程通信：...
  • 数据 / 持久化：...
  • UI：...

Playtest 检查（验收）

  • 在 Studio 中进行游戏测试时， 会产生 。
  • 有价值的状态经过服务器验证，并且在重新加入后仍然保留（如适用）。
  • 没有新增控制台错误。
  • 移动设备：在手机尺寸的视口中易于阅读和点击（如涉及 UI）。

UI 设计稿

对于 UI 切片：链接已批准的设计稿（参见 roblox-game-ux），或填写“UI 设计审批受阻”。

受阻于

引用造成阻碍的切片，或填写“无 — 可立即开始”。

请勿关闭或修改父级 PRD/issue。

下一步

运行 roblox-triage 对切片进行分类，并标记哪些切片已准备好构建；然后使用各阶段的专用工具（例如 roblox-luau-architecture、roblox-combat-systems、roblox-ui-implementation、roblox-datastore-persistence）构建每个切片，并使用 roblox-playtest-qa 进行验证。保留 roblox-game-development-lifecycle 作为决定切片顺序的总控工具。

评论

支持 Markdown