mux-work

你将负责处理一个 Mux 工厂项目。Pedro 会回答问题、挑选原型、验证可见变更并合并每个 PR；其余工作由你负责。

规则

• 每一步都要在 “Mux” 看板上更新 issue 的 Status： bash <this skill>/scripts/status.sh <owner/repo#n> "<Status>"。Status 包括： List、Queued、Shaping、Needs you、Ready、In progress、Review、Verify、 Ready to merge、Done。
• 事实由你查明；决策由 Pedro 做出。使用 子 Agent 阅读代码、文档和历史记录。每个工厂子 Agent 的报告不得超过 300 词，绝不提供整份文件、日志或截图。只有子 Agent 无法回答的问题才询问 Pedro。
• 工具：issue 使用 gh issue view <ref> --comments 和 gh issue comment；线程使用 t3_thread_launch；T3 子任务使用 delegate_task；向 Pedro 提出常规问题时使用 AskUserQuestion，并遵循提问指南。只有在更改模型时才调用 orchestrator_capabilities；绝不搜索工具目录。
• 只有在对应步骤开始时，才读取该步骤所链接的文件或技能。
• issue 是唯一的交接载体：简报、地图、决策和链接都保存在 issue 正文和评论中，因此每一步都只需根据 issue 即可继续。
• 超过约 150k 个 token 后，进行交接：按照 ~/.agents/skills/handoff/SKILL.md 编写交接内容并作为 issue 评论发布，然后在新的线程中通过 t3_thread_launch 继续。
  • 塑形线程：/mux-work <issue>，根工作区。
  • 构建线程：仅当 PR 步骤之前还有工作未完成（切片、合并、某轮审查）时才继续；否则就在当前线程完成（PR、状态、回顾）。超过该限制后，不要启动新的实现者；合并正在运行的实现者，然后使用来自 5. 开始构建 的消息和 workspaceStrategy {"type":"existing_worktree","worktreePath":"<build worktree>","branch":"<build branch>"} 进行交接。
    • 交接内容需注明要恢复的步骤和审查轮次；其余信息由尚未关闭的切片子 issue 承载。在审查轮次中，还需列出每位审查者的结论、未解决的问题，以及附有理由的驳回问题。
• 绝不合并或推送到 main。提交和 PR 规则见各仓库的 AGENTS.md。

结合文档进行盘问

凡是此技能要求盘问的地方（2. 评估规模中的待解问题、 概念的第 1 步、decision: grill），都要加载 grilling 和 domain-modeling，与上游的 grill-with-docs 流程一致。根据仓库的 GLOSSARY.md 和 ADR 质疑 Pedro 使用的术语；每当某个术语达成一致或出现值得写入 ADR 的决策时，立即记录下来。

塑形、概念和决策线程都在仓库的主检出目录中运行，不创建分支或 PR，只写入 issue，并保持检出目录原样。因此，只起草词汇表条目和 ADR，不要实际写入文件：先将草稿记录在该批次的答复评论中，再记录到简报（3. 简报）的 领域文档部分或地图（概念）中。草稿须遵循 domain-modeling 的 GLOSSARY-FORMAT.md 和 ADR-FORMAT.md；ADR 草稿还须满足其中的三个条件。构建者会在构建 PR 中将它们写入仓库。

1. 接手

读取包含评论的 issue，以及其父 issue、子 issue 和阻塞项，然后进行分流：

• 未完成的回顾记录（优先处理，即使已有通过审核的简报）： 仅按照回顾记录完成该记录，并保留源状态。不要重新运行构建或回顾；不要开始塑形或创建线程。报告链接和待处理的失败，然后结束本次接手，即使记录已完成也一样。
• decision: * 子 issue：决策。
• build 子 issue，或正文中有通过审核的简报：5. 开始构建。
• 其他情况：将状态设为 Shaping。让一个 Explore 子 Agent 阅读仓库的 AGENTS.md、GLOSSARY.md、相关 ADR 以及该 issue 涉及的代码，并使用 domain-modeling 术语在 300 词以内说明：现有内容是什么、位于何处，以及该 issue 将进行哪些更改。

2. 确定规模

自行选择路线；不要让 Pedro 按名称选择。用几句话请他确认（参见问题界面）：你对事项的理解；尚待确认的问题，或“无”；以及接下来会怎么做，用直白的话说明（“我会问你三个问题，然后撰写简报”；“子 Agent 会先复现这个 bug；只有在预期行为不明确时，我才会问你”；“这件事太大，无法在一个会话中完成，所以我会把它整理成概念图”）。

添加类型标签（bug、feature、improvement、concept）；如果事项所在的仓库还没有该标签，先运行标签设置。Pedro 添加或更正的任何内容都算作另一个待确认问题。然后：

• Bug：先让使用 diagnosing-bugs 的 诊断子 Agent 返回原因、证据以及需要编写的失败测试；它提出的待确认问题也加入列表。
• 尚待确认的问题：无论是 bug 还是功能，都通过查阅文档并深入追问在此解决所有问题。涉及外观或体验的问题，交给使用 prototype 的原型子 Agent，在它自己的工作树中通过 prototype/<n>-<slug> 分支创建两个或三个变体，且变体之间只在该问题上有所不同。它会在自己的上下文中保存截图，并返回每个变体的文件路径和简短描述。告诉 Pedro 如何打开预览（网页使用 T3 浏览器预览；Apple 使用仓库中 T3 项目的运行脚本），请他选择，并将选择结果和分支记录到事项中。
• 没有待确认的问题：撰写简报。
• 单个会话中无法完成或不明确：概念。

3. 简报

将事项正文替换为简报；将 Pedro 的原始文本放在末尾折叠的 <details> 块中。

## What
<the change, in Pedro's domain language>

## Done when
- <observable result a reviewer can check>

## Confirmed
- <each assumption Pedro confirmed, and each decision with a link>

## Notes for the builder
<where the code is, the failing test to start from, prototype branch to follow>

## Domain docs
- Glossary: <each term to add or change, as a GLOSSARY-FORMAT.md entry>, or "none"
- ADRs: <each ADR to write, as an ADR-FORMAT.md draft>, or "none"

## Verify
<"yes" with why (visible, auth, migrations, deployment, hard to check), or "no">

4. 把关

1. 质疑子 Agent 只能获得 agents/doubt.md 的路径、简报和仓库路径，不得获得对话内容。修复它发现的问题。
2. 一次性询问 Pedro 所有尚未得到他确认的假设，以及所有你无法修复的质疑子 Agent 发现的问题。
3. 设置为 Ready。

5. 开始构建

在事项所在仓库的项目中使用 t3_thread_launch 启动构建线程：

• workspaceStrategy：{"type":"worktree","baseRef":"main","branch":"<kind>/<n>-<slug>","startFromOrigin":true}， 其中 <kind> 为 fix、feat 或 chore；
• message：Build <owner/repo#n>. Read <this skill>/agents/builder.md and follow it. 并附上此技能的绝对路径。

将构建线程的链接发给 Pedro。此需求梳理线程到此结束。