implement-issues

实现 Issues

使用 Agent 构建未解决的 Issue，每个 Issue 对应一个 Pull Request。每个 Issue 都会按一个人处理它的流程推进：

1. Superpowers 根据 Issue 编写规格说明和计划；
2. 由 Superpowers 完成构建；
3. 创建 Pull Request 并进行代码审查；

但过程中没人回答问题。Agent 替用户做出的每项决定都会记录在其 Pull Request 中，由用户审查。

每个 Issue 由两个 Agent 负责。规划者编写规格说明和计划。构建负责人执行计划并回应审查。启用计划审批后，用户会先在草稿 Pull Request 中审查规格说明和计划，然后构建负责人再开始；后续运行会接着处理已获批准的内容。

构建完成后，Pull Request 会以草稿状态创建。第二个 Agent 会对其运行 review-prs，然后构建负责人使用 answer-pr-reviews 回应审查。审查得到回应且检查通过后，Pull Request 会标记为准备就绪。

你是调度者。Agent 在各自的工作树中编写内容；你负责推送每个分支、创建其 Pull Request，并判定每个 Agent 的工作。只有在你亲自确认检查通过后，才会将内容标记为准备就绪。

规格说明、计划和构建都由 Superpowers 负责。这项技能会根据用户的设置，回答 Superpowers 本来会向人询问的问题——使用哪种执行模式、哪个模型、进行多少轮修复。它不会改变 Superpowers 内部的工作方式。

这项技能描述的是操作——“调度 Agent”“选择模型”等——而不是工具。请使用你所在平台的对应方式。

要求

• Superpowers（brainstorming、writing-plans、subagent-driven-development、 executing-plans、finishing-a-development-branch、 verification-before-completion），以及 fetch-issues、 superpowers-issue-bridge、review-prs 和 answer-pr-reviews 技能。如果 缺少其中任何一项，请指出名称并停止。
• 一个 GitHub 仓库和 gh，且 gh auth status 通过——Pull Request 及其审查都存放在此处，无论 Issue 存放在哪里。

设置

三个设置会影响一次运行。仓库中的 docs/agents/delivery.md 保存已设定的值；其格式见 assets/delivery.md。

• 工作量——low、medium 或 high。按以下优先顺序确定：运行参数（/implement-issues low、“at medium effort”）、文件中的 Effort 行，或 Stage 2 中的问题。它决定：

  	low	medium	high
  构建模式，回答 writing-plans 的执行问题	一个 Agent，使用 executing-plans	按任务，使用 subagent-driven-development	按任务，使用 subagent-driven-development
  每项任务审查的修复轮数	—	2	5
  review-prs 代码审查	关闭	关闭	开启
  审查修复后你执行的完整检查	以 CI 结果为依据；仅当 Pull Request 没有 CI 时才运行	是	是
  finishing-a-development-branch 自带的测试套件运行	若自 Stage 5 以来 HEAD 未变，则跳过	若自 Stage 5 以来 HEAD 未变，则跳过	运行
  CI 修复尝试次数	1	2	3
  计划修订轮数	1	2	3

  对于所有工作量等级，构建结束时都会运行 Superpowers 的整分支审查；首次推送前由你运行完整检查；不会合并任何内容。

• 计划审批——开启或关闭；如果文件中未说明，则关闭。

• 模型，每个席位一个。每个值可以是层级（cheap、standard、strong），并根据此平台对应的 Tiers 表查找；也可以是 session、确切的模型名称，或——仅限实现者——by-task，将选择权交给 subagent-driven-development 自身的规则。文件未设置的席位使用以下回退值：

  席位	调度方	未设置时
  planner、build-lead、pr-reviewer	你	会话模型
  implementer	Superpowers	在 Stage 2 中询问
  spec-check、task-reviewer、re-reviewer、escalation、final-reviewer	Superpowers	该技能自身的规则
  pr-code-reviewer	review-prs	该技能自身的规则

阶段 1 — 构建队列

1. 使用 fetch-issues 获取未关闭的问题。如果用户指定了问题（“#12 and #15”），则只保留这些问题。

2. 阅读 docs/agents/issue-tracker.md 中的 Linking（关联）部分——该部分决定每个拉取请求要写什么内容来关闭对应问题。如果存在 docs/agents/delivery.md，也要阅读。

3. 查找每个问题未关闭的拉取请求和分支（feat/42-*、 fix/42-*）。正文包含 `` 的未关闭拉取请求是此技能的计划拉取请求：

   • 标记为 plan-approved → 构建；
   • 存在未回复的审查评论——即未解决的讨论串，其最后一条评论并非以 `` 结尾 → 修订计划；
   • 否则 → 等待用户。

   对于该问题，任何其他未关闭的拉取请求或分支 → 跳过，并记录原因。既没有拉取请求，也没有分支 → 规划。

4. 如果某个问题的正文引用了另一个已排队的问题，则该问题依赖于后者：等后者的拉取请求标记为 ready 后再开始；从后者的分支而非基础分支创建分支，并在拉取请求中说明这一点。如果后者结束时没有 ready 的拉取请求，则跳过此问题并记录原因。

5. 查找基础分支——远程仓库的默认分支——并获取它。

打印队列——引用、标题、分支、操作（规划、修订计划、构建）、依赖项——然后列出等待和跳过的项目。

阶段 2 — 确定设置，然后询问如何运行

开始派发前必须先询问。

1. **设置。**打印工作量及其来源、计划审批设置，以及此平台上每个席位解析出的模型。将每个解析出的模型与当前平台派发所接受的模型逐一核对——即其模型选项或生成白名单。有任何模型不受支持，都必须停止运行：指出席位、对应值及其来源。这也包括其他平台上的精确模型名称，以及没有此平台对应列的档位。

   对于文件中未明确的设置，询问用户：本次运行未提供参数时的工作量；文件中没有对应条目时的计划审批设置；文件未设置实现者模型时的实现者模型——并提供派发所接受的模型选项，绝不能使用从其他平台记住的模型名称。如果平台无法针对每次派发单独设置模型，请说明这一点，并为每个席位使用默认模型。然后询问本次运行是否采用这些设置，或者仅针对本次运行覆盖其中任何设置。

   如果询问了任何内容，请提出将其保存到 docs/agents/delivery.md：展示文件差异，并且只有用户同意后才写入。仅当用户明确要求时，才保存本次运行的覆盖设置。

2. **顺序还是并行？**顺序运行一次处理一个问题。并行运行最多同时处理 N 个问题——询问 N 的值，并建议设为 3。只有当平台能够同时运行多个派发的 Agent 时，才提供并行选项。无论采用哪种方式，从派发开始，直到该问题停止，期间都占用一个位置：等待计划审批、标记为 ready，或已结束。

打印队列后，用户的回答即表示同意执行整次运行——针对每个问题：推送其分支；打开草稿计划拉取请求，并在缺少 plan-approved 标签时创建该标签；推送计划修订并回复相关评论；打开或转换草稿拉取请求；在其上发布审查意见；推送针对该审查意见的修复并回复相关评论；推送用于修复失败 CI 检查的更改；并将其标记为 ready。

阶段 3 — 规划

对于每个需要规划的问题，创建分支和工作树，然后分派规划 Agent：

• 分支： 对标记为 bug 的问题，使用 fix/<ref>-<slug>；否则使用 feat/<ref>-<slug>。<ref> 是不带 # 的问题编号（42、 PROJ-123）；<slug> 是标题的小写形式，将每段不属于 a-z0-9 的字符替换为 -，并截短至 40 个字符。

• 工作树： .worktrees/<ref>-<slug>，使用 git 从基础分支或依赖项的分支创建。不要将 .worktrees/ 纳入提交： 如果 git check-ignore -q .worktrees 失败，则将其添加到 .git/info/exclude。

  git worktree add -b "<branch>" ".worktrees/<ref>-<slug>" "origin/<base>"
  

• 规划 Agent： 填写 assets/planner-brief.md，不创建规划拉取请求， 并将其作为后台 Agent 分派到规划席位。

对于每个需要修订的规划，如果问题的工作树干净，则重复使用； 否则，从已推送的分支创建一个工作树 （git worktree add ".worktrees/<ref>-<slug>" "<branch>"）。统计已完成的 修订轮数——即规划拉取请求上包含 `` 的对话评论。 达到工作量上限时，将其留在等待状态并记录原因。否则，根据 assets/planner-brief.md 分派规划 Agent，并注明规划拉取请求。

规划 Agent 汇报后：

1. 如果汇报为 BLOCKED 或 NEEDS_DESIGN_SESSION，或分支上没有提交：不创建拉取请求。保留工作树并记录原因。
2. 修订： 确认已推送并回复，然后在规划拉取请求上发布对话评论——Plan revision <n> of <cap>. ——并将其留在等待状态。
3. 启用规划审批： 推送分支并创建草稿规划拉取请求—— gh pr create --draft，标题为 plan: <issue title> (<reference>)，正文使用 assets/plan-pr-body.md，基础分支设为基础分支或依赖项的分支。 如果 gh label list 未显示 plan-approved，则先创建该标签。 将问题留在等待状态。
4. 未启用规划审批： 使用规划 Agent 的规格说明和规划，直接进入阶段 4。

阶段 4 — 构建

对于每个需要构建的问题，如果其工作树干净，则重复使用；否则，从已推送的分支创建一个。填写 assets/build-brief.md，并将其作为后台 Agent 分派到构建负责人席位。顺序执行：一次处理一个问题。并行执行：最多同时处理 N 个问题，每完成一个就开始下一个。保留每位构建负责人的身份；阶段 5 和 8 可能会向其发送消息。

阶段 5 — 验证每个已构建的问题

构建负责人汇报后：

1. 如果汇报为 BLOCKED 或 NEEDS_DESIGN_SESSION，或分支上没有新提交，则不创建拉取请求。保留工作树并记录原因。
2. 在问题对应的工作树中自行检查：阅读 git log origin/<base>..HEAD 和差异，并运行项目的测试、 lint 和类型检查命令（从 AGENTS.md 或项目清单中获取）。 将每条命令的输出写入工作树 git 目录下的日志文件，并读取其退出代码、 摘要以及任何失败内容的末尾部分——不要读取整个日志。Agent 声称“测试通过”只是说法，不是证据。
3. 如果检查失败，向同一位构建负责人发送一条包含失败详情的消息，然后重新验证。仍然失败：不创建拉取请求；记录失败原因。

阶段 6 — 打开草稿拉取请求

通过 finishing-a-development-branch 合并每个已验证的分支。它的菜单已回答——推送并创建拉取请求，且设为草稿——所以不要等待。对于高投入以下的工作，如果 HEAD 自上次未变，阶段 5 的检查运行就是它的步骤 1。

• **标题：**采用 Conventional Commit 格式，并以问题引用结尾，例如 feat: confirm waitlist emails (#42)。
• **正文：**填写 assets/pr-body.md。其中的链接行来自跟踪器的 Linking 部分。首先自行判断报告中每项未完成的事项：凡是本仓库无法进行的更改，都可以作为后续事项，后续事项绝不会导致工作被视为部分完成。如果没有其他未完成事项，写入完成引用（在 GitHub 上为 Closes #42）；否则写入部分完成引用（Relates to #42），并说明剩余事项。如果跟踪器的 Finishing PR 为 None，则没有完成引用：写入部分完成引用，并说明这项工作是否已完全解决该问题。这是 superpowers-issue-bridge 对无人值守运行的规则。
• **基准分支：**基准分支；如果是依赖项问题，则使用该依赖项的分支。
• 已批准的计划拉取请求就是此问题的拉取请求：推送到它的分支，然后使用上面的标题和正文，通过 gh pr edit <number> --title <title> --body-file <file> 设置。它会保持为草稿。

拉取请求打开后，保留每个工作树——审查修复会在其中进行。

阶段 7 — 审查拉取请求

安排一位新的 Agent 担任 pr-reviewer，不要使用 planner 或 build lead，让它在 <owner/repo> 上运行 review-prs #<number>，并告知它：

• 用户对本次运行的许可包含发布审查意见；
• 对于高投入以下的工作，关闭代码审查，因为构建过程中的全分支审查已经覆盖了代码。

它会将审查结果作为评论发布到拉取请求中，并报告审查 URL。审查不会更改本地内容，因此可以在其他问题构建期间运行。

没有发布审查：将拉取请求保留为草稿，并记录原因。审查没有发现问题：进入阶段 8 的步骤 3。

阶段 8 — 回复审查并将拉取请求标记为可合并

1. 告知 build lead——或者，如果已无法联系它，就安排一位新的 Agent 担任 build-lead，并让它进入同一个工作树——在该工作树中对 <owner/repo> 运行 answer-pr-reviews #<number>，并告知它用户对本次运行的许可包含推送修复并回复每条评论。
2. 对于中等和高投入的工作，使用 verification-before-completion 验证已推送的 HEAD，并自行运行阶段 5 的检查。如果有检查失败，只向 build lead 发送一次失败信息，然后重新检查。对于低投入的工作，CI 是审查修复的证据；只有在拉取请求没有 CI 时才运行阶段 5 的检查。
3. 等待拉取请求针对已推送 HEAD 的 CI 检查——gh pr checks <number> --watch。如果显示没有检查，就无需等待。本地通过不等于 CI 通过：检查可能仅在 CI 中失败，例如因为运行时不同、缺少变量，或项目的本地命令跳过了某个步骤。若有检查失败，请将失败检查的名称和日志（gh run view <run-id> --log-failed）发送给 build lead，要求它修复、提交并推送此分支——绝不要强制推送。然后再次运行步骤 2，并再次等待 CI，最多尝试该投入级别规定的 CI 修复次数。
4. 检查通过且每条审查评论都已回复后，将拉取请求标记为可合并——gh pr ready <number>。如果检查仍然失败，或某项成立的审查意见尚未修复，则将其保留为草稿，并记录原因。

阶段 9 — 报告

用一张表列出：问题、分支、拉取请求 URL 或没有拉取请求的原因、状态（等待计划审批、就绪，或草稿及原因）、本地和 CI 中的检查结果、按严重程度分类的审查发现及修复数量，以及 Agent 做出的决定数量。表格上方列出本次运行的投入和计划审批情况；表格下方列出每个席位使用的模型，以及平台提供的每个 Agent 的令牌用量或耗时。然后列出阶段 1 中所有等待处理或跳过的问题及原因。

合并带有部分引用的拉取请求后，其问题仍保持开启。对于每个仍有未完成工作的拉取请求，点名说明未完成的工作，并向用户询问一次：这是否已完全解决该问题？若用户回答是，就用最终引用替换其链接行（gh pr edit <number> --body-file <file>），并将未完成的工作保留为后续事项。

对于没有最终引用的跟踪工具——例如本地 Markdown，或没有任何集成会关闭问题的 Jira 或 Trello 看板——无需替换链接行。对于每个已完全解决其问题的拉取请求，包括上述每个用户回答“是”的情况，都告知用户合并后需要在跟踪工具中手动执行的关闭步骤。

不要做的事

• 不要合并、启用自动合并或批准拉取请求——将其标记为就绪后，交由用户接受这项工作。
• 不要推送基础分支，也绝不强制推送。
• 不要把 Agent 的报告当作证明——在首次推送前以及每次投入时，都要亲自运行检查。
• 不要为已有拉取请求的问题再创建拉取请求，获批的计划拉取请求转换为其他类型的拉取请求除外。
• 不要在计划拉取请求没有 plan-approved 标签时据此开展构建工作，也不要自行添加该标签——审批权属于用户。
• 不要提供或调度平台调度功能不接受的模型，也不要悄悄改用其他模型。
• 不要在此技能或其资源中写入模型名称；模型名称只能放在 docs/agents/delivery.md 中，由用户选择。
• 不要在未展示差异并获得用户同意的情况下，将设置保存到 docs/agents/delivery.md。
• 除非用户在阶段 9 表示拉取请求已完全解决该问题，否则只要本仓库能完成的工作仍未完成，就不要写入最终引用。不要仅为后续事项编写部分引用。
• 不要创建缺少 Decisions 部分或该部分含糊不清的拉取请求——这是用户唯一能看到 Agent 替他们做出的选择的地方。
• 不要让规划者或构建负责人审查自己的拉取请求。
• 如果审查评论尚未回复，或推送的提交在本地或 CI 中检查失败，就不要将拉取请求标记为就绪。