mcpField
R
roblox-triage

roblox-triage

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

关于 roblox-triage

roblox-triage 用于按明确状态处理 Roblox 缺陷和功能切片，帮助团队形成可执行的构建简报，并检查复现情况与 UI 设计要求。

主要功能

  1. 01区分缺陷与功能增强
  2. 02按分诊状态推进事项
  3. 03在 Studio Playtest 中复现缺陷
  4. 04要求 UI 设计获批
  5. 05生成构建简报和分诊记录

适用场景

  1. 01判断 Roblox 缺陷是否可开始修复
  2. 02补充功能切片缺少的细节
  3. 03标记缺少已批准设计的 UI 工作
  4. 04将已复现缺陷交给调试流程

安装

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

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

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

附带文件BUILD-BRIEF.md

详细介绍

Roblox 分流

通过一个小型状态机推进切片和缺陷报告，确保任何标记为“ready to build”的项目都已充分明确，可以在一次专注的工作中完成构建，并且完成后可以进行试玩测试。

跟踪器位置和标签词汇应已在 CLAUDE.md / docs/agents/ 中提供。如果没有，请运行 setup-roblox-skills。如果跟踪器是 GitHub，请在任何由 AI 编写的评论前加上 > *Generated by AI during triage.*。

参考

  • BUILD-BRIEF.md — 如何为 ready-to-build 切片编写持久有效的构建简报。

角色

两种类别角色：

  • bug — 场景中有内容出故障。
  • enhancement — 新切片／功能。

五种状态角色：

  • needs-triage — 尚未评估。
  • needs-info — 等待用户提供决定或细节。
  • ready-to-build — 规格完整；Agent 无需补充上下文即可一次性完成构建。
  • needs-human — 需要用户参与（Studio 操作、设计决策、平衡性判断、购买测试）。
  • wontfix — 不会处理。

每个已分流项目都必须且只能有一个类别角色和一个状态角色。这些是规范名称；实际的标签／状态字符串见 docs/agents/triage-labels.md。

常规流程：needs-triage →（needs-info ↔ needs-triage）→ ready-to-build / needs-human / wontfix。用户可以覆盖；遇到任何异常情况时，请标记出来并先询问。

UI 设计门槛

任何会改变面向用户 UI 的切片，在存在已批准的 Roblox UI 设计产物之前都不能变为 ready-to-build（该产物的内容见 roblox-game-ux：布局、状态，以及移动端／平板／桌面端行为，并标记为 Status: approved）。如果缺少该产物或仍处于草稿状态，则将切片设为 needs-human，并注明必须先完成 UI 设计步骤。

调用方式

用户会用自然语言调用此功能：“接下来应该构建什么？”、“分流此缺陷”、“这个切片准备好了吗？”、“将 coin-pickup 切片标记为 ready to build”。请理解并采取行动。

展示需要关注的内容

按时间从早到晚展示三类内容：未分流、needs-triage，以及有新用户输入的 needs-info。每项显示一行摘要，并让用户选择。

分流单个项目

  1. 收集上下文。 完整阅读项目内容（以及之前的分流备注，避免重复询问）。通过 roblox-studio-workflow 连接并检查相关脚本／实例。对于 UI 项目，检查设计产物。
  2. 给出建议。 说明建议的类别和状态，并解释理由，同时简要概述相关的场景状态。等待用户指示。
  3. 复现（仅限缺陷）。 在进行其他操作前，先尝试在 Studio 试玩中复现，并读取 get_console_output。确认复现（并找到出错代码路径）能让构建简报有力得多；无法复现则是强烈的 needs-info 信号。将难以处理的缺陷交给 roblox-debugging-bugfix。
  4. 明确需求（如有需要）。 如果项目描述含糊，进行一轮简短的深入询问（参见 roblox-game-ideas 的深入提问模式），以明确决策。
  5. 落实处理结果：
    • ready-to-build — 发布构建简报（BUILD-BRIEF.md）。对于 UI，附上已批准产物的路径。
    • needs-human — 使用相同结构，但说明为何无法委派。
    • needs-info — 发布分流备注：已确认的信息，以及仍待解答的具体问题。
    • wontfix — 简要说明原因；对于功能增强，注明原因，避免之后再次被推荐。

快速覆盖

如果用户说“将 X 标记为 ready to build”，则信任用户，在检查是否存在冲突的状态角色和 UI 设计门槛后应用该状态。如果缺少 UI 产物，请明确说明缺少什么，并在应用 ready-to-build 前请求用户明确确认覆盖。

下一步

使用对应阶段的专家（roblox-luau-architecture、roblox-combat-systems、roblox-ui-implementation、roblox-datastore-persistence 等）构建 ready-to-build 切片，然后使用 roblox-playtest-qa 和 roblox-mobile-playtest 进行验证。如果已对 Bug 进行分诊，则将其交给 roblox-debugging-bugfix。返回 roblox-game-development-lifecycle，以选择下一个切片。

评论

支持 Markdown