Back to Details

implement-spec

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese
You have been provided a spec. This spec should have tickets associated with it, describing how to implement the spec.
The issue tracker should have been provided to you. If not, tell the user to run 
/setup-matt-pocock-skills
.
The goal is the entire spec implemented on a single integration branch, with every ticket resolved the way the issue tracker closes work.
The tickets are not a list of steps. They are a task graph with blocking relationships between them. This means there is always a frontier of tickets which are ready to be grabbed.
Communication to and from subagents should be sparse. Communicate primarily through context pointers: to the spec, tickets, research notes, and previous commits. Don't duplicate information already available via pointers.
Implementer subagents should be run in the background where possible for maximum concurrency.
你已获得一份 spec。该 spec 应关联有 tickets，用于说明如何实现该 spec。
应当已向你提供 issue tracker。如果没有，请提示用户运行 
/setup-matt-pocock-skills
。
目标是在单个 integration branch 上完整实现整个 spec，并按照 issue tracker 关闭工作的方式解决每个 ticket。
tickets 并不是一组步骤。它们构成一个带有阻塞关系的 task graph。这意味着始终存在一个可直接领取的 frontier tickets 集合。
与 subagents 之间的通信应尽量精简。主要通过 context pointers 传递信息：指向 spec、tickets、研究笔记和此前的 commits。不要重复已经可以通过这些 pointers 获取的信息。
Implementer subagents 应尽可能在后台运行，以实现最大并发度。

Steps

步骤

  1. Read the spec and tickets to understand the task graph.
  2. (optional) Use an exploration subagent to conduct any exploration required by the tickets - relevant codebase files or external documentation. Ensure the exploration subagent can save files - it should save its markdown notes in a directory outside the repo, accessible by all future subagents. This lets implementer subagents focus on implementation rather than exploration.
  3. Create the integration branch. If the issue tracker closes work through PRs, or the user asks for one, open a draft PR after the first merge in step 5 (a branch with no commits ahead of main can't open one), marked as closing the spec and tickets.
  4. Use implementer subagents to implement each ticket, each in its own worktree on its own branch. Each implementer subagent:
    • confirms its worktree is based on the integration branch before starting, and resets onto it if not;
    • calls the Skill tool with 
      tdd
      to build the ticket;
    • merges the integration branch tip into its own branch before reporting done
  5. Once an implementer subagent completes, merge its work to the integration branch with a merger subagent.
  6. If this changes the frontier of available tickets, kick off more implementer subagents to work on the new tickets. This allows for maximum concurrency.
  7. Once all tickets are complete, call the Skill tool with 
    code-review
    on the integration branch. Fix all issues raised by the code review in a single implementer subagent.
  8. If a draft PR exists, mark it ready for review. Otherwise, resolve each ticket the way the issue tracker closes work, and report the integration branch.
  9. Clean up all implementer subagent worktrees.
  1. 读取 spec 和 tickets，以理解 task graph。
  2. （可选）使用 exploration subagent 执行 tickets 所需的任何探索工作——查找相关代码库文件或外部文档。确保 exploration subagent 能够保存文件——它应将 Markdown 笔记保存到 repo 之外的目录中，供所有后续 subagents 访问。这样，Implementer subagents 就可以专注于实现，而不是探索。
  3. 创建 integration branch。如果 issue tracker 通过 PRs 关闭工作，或用户要求创建一个，则在步骤 5 的首次 merge 之后打开一个 draft PR（一个没有任何 commits 领先于 main 的分支无法打开 PR），并将其标记为关闭该 spec 和相关 tickets。
  4. 使用 Implementer subagents 实现每个 ticket，每个 subagent 使用自己的 worktree 和 branch。每个 Implementer subagent：
    • 在开始前确认其 worktree 基于 integration branch；如果不是，则将其 reset 到 integration branch 上；
    • 调用 Skill 工具并使用 
      tdd
      构建该 ticket；
    • 在报告完成之前，将 integration branch 的 tip merge 到自己的 branch。
  5. 一旦某个 Implementer subagent 完成，使用 merger subagent 将其工作 merge 到 integration branch。
  6. 如果这改变了可用 tickets 的 frontier，则启动更多 Implementer subagents 来处理新的 tickets。这可以尽可能提高并发度。
  7. 所有 tickets 完成后，在 integration branch 上调用 Skill 工具并使用 
    code-review
    。由单个 Implementer subagent 修复 code review 提出的所有问题。
  8. 如果存在 draft PR，将其标记为 ready for review。否则，按照 issue tracker 关闭工作的方式解决每个 ticket，并报告 integration branch。
  9. 清理所有 Implementer subagent 的 worktrees。