implement

实现

使用此技能端到端实现已批准的 PRD 或范围明确的任务。

这是 prd 的执行对应项。

implement 负责推动任务直至完成，包括修复。它不会重新实现验证：它会将判断委托给 verify，作为其工作循环的关卡（参见最终验证）。verify 仍是判断如何算完成的唯一依据，也可以独立运行，对任何差异进行单独审查。

输入

如果任务来自 prd，请阅读 .dev/<topic-slug>/ 下的产物：

• prd.md — 契约：范围、非目标、需求、验收标准、任务和验证计划。验收标准是验证器据以检查的评分标准。
• checklist.md — 任务清单。将其作为实时清单使用，不要重新生成。
• context-notes.md — 项目背景。请阅读，以避免重新探索 prd 已经确认的内容。

如果这些产物不存在（用户直接提供了范围明确的任务、关联的规范或请求），则回退到该单一来源文档，并据此创建清单。

准备情况检查

编辑代码前：

1. 阅读上述输入（.dev/<slug>/ 下的产物，或回退流程中的单一来源文档）。
2. 明确范围、非目标、需求、验收标准和验证方式。
3. 检查 git status --short。
4. 阅读可能需要修改的实际文件。
5. 如果缺少必要的前置工作、凭据、产品决策、破坏性数据变更或结构性批准，请停止并询问。

实时清单

如果存在 checklist.md，将其作为工作清单使用；否则，根据来源文档创建一份。

跟踪以下内容：

• 需求
• 验收标准
• 实现任务
• 验证命令
• 浏览器或运行时 QA 场景
• 人工检查项

除非验收标准已有证据或存在明确的阻塞项，否则不要将任务标记为已完成。

创建结构化任务列表

如果 checklist.md 存在且包含 3 个或更多任务，请使用 TaskCreate 根据它创建结构化任务列表，而不是使用扁平的 TodoWrite。这样可以在整个工作循环中保留需求追溯关系、任务顺序和证据。

对于 checklist.md 中的每个 T<n> 任务：

1. 使用 TaskCreate 创建一个任务。将清单标签写入 metadata：
   • metadata.req — (req: ...) ID。
   • metadata.ac — 该任务负责的 (ac: ...) ID。
   • metadata.checklistId — T<n> ID，用于解析 after:。
2. 创建所有任务后，关联任务顺序：对于每个 (after: T1) 标签，在依赖任务上设置 addBlockedBy，并指向前置任务的任务 ID。
3. 将验收标准和人工检查项保留在 Markdown 清单中；任务列表用于跟踪可执行的工作，验证器负责评判验收标准。

如果不存在 checklist.md、任务数量较少，或工作只是一个简单直接的改动，则回退到 TodoWrite。对于琐碎任务，不要创建结构化任务列表——这种流程形式不值得。

实施循环

按依赖顺序处理任务。使用结构化任务列表时，选择下一个 blockedBy 为空的任务（checklistId 最小者优先）；绝不要开始仍受阻的任务。

对于每个任务：

1. 在编辑前将其标记为 in_progress（TaskUpdate），以便进度清晰可见。
2. 重新阅读相关文件。
3. 做出满足映射需求（metadata.req）的最小改动。
4. 避免无关重构。
5. 保留用户在工作树中的改动。
6. 有意义的编辑后，运行最小且有用的检查。
7. 在执行过程中验证映射的验收标准（metadata.ac），验证深度应与标准的实际要求相符——不要把所有验证都推迟到最后一轮：
   • 可由机器检查的标准（SQL 查询、curl、构建、单元测试、生成的输出）→ 立即运行检查并记录实际输出。
   • 运行时／浏览器标准 → 如果可以，立即测试该流程（使用验证者会使用的同一个 playwright-cli）；如果确有前置条件阻碍测试（例如无法自动化的 OAuth 登录），应将其记录为具体阻碍，而不是假定测试通过。
8. 随着工作进展记录证据——将其写入任务（metadata.evidence），包括运行的命令、文件及行号、观察到的结果，以便最终验证者能在此基础上继续，而不必从头开始。
9. 只有在映射的验收标准（metadata.ac）有实际证据或具体阻碍时，才将任务标记为 completed。阅读代码并假定其有效，不算证据。未完成或未经验证的改动应保持 in_progress。

如果需要新任务，仅当它对应已批准的需求，或属于纯验证／发布卫生事项时，才创建该任务（TaskCreate）；同时为其标记 metadata.req。添加新的产品范围或实质性改变已批准的结构前，请先询问。

最终验证

先完成实现。然后，只委托独立验证者一次来判定是否完成，不要自行评判。

编写更改的上下文最不适合评判这项更改。因此，构建完成后，启动一位未编写代码的新验证者，让它依据验收标准进行评判。

1. 使用 Task 工具启动一个独立验证子代理。向它提供：
   • prd.md（或任务）中的验收标准作为评判依据——每一项标准都要提供，不得只提供其中一部分，
   • PRD 中的 Verification - Agent 和 Verification - Human 两个部分作为可用方法。验证者拥有与你相同的工具，包括 playwright-cli，因此，归在 Verification - Human 下的标准并不会自动超出其范围：如果无需人工即可执行浏览器／API／数据库步骤，验证者就必须执行。
   • 更改范围（git status --short／差异）和相关文件，
   • 你在构建过程中收集的证据。 指示它遵循 verify 技能：按照适当的验证级别评判每一项验收标准，并按 verify 输出格式报告总体结论和逐项结果（已检查／失败／未检查）及证据。对于只能通过阅读代码确认、而无法通过运行来确认的标准，必须报告为 Blocked（注明缺少的前置条件，例如“需要经过身份验证的会话”），不得默认为已通过。验证者仅负责报告，不得修改代码。
2. 阅读验证结论。verify 会返回 Pass | Partial | Fail | Blocked 之一，并附上逐项详情。只有每项标准都有真实证据时，Pass 才有效；如果 Pass 中仍有运行时／浏览器标准未检查，则应视为 Partial，并要求验证者实际运行这些检查。
   • Pass（所有标准均满足且有证据）→ 完成。
   • Partial 或 Fail → 修复验证者指出的具体缺陷（文件、行号、失败案例），然后再运行一次验证者确认。第二次验证后停止；如果仍然失败，报告剩余缺陷，不要反复尝试。
   • Blocked → 停止并报告需要人工处理或决策的阻碍。将其列为剩余事项；不得在 Pass 之下掩盖。

不得依据自己给出的结论、跳过的验证或弱于验收标准要求的目标宣称完成。请报告具体缺陷。

最终报告

## Status

Done | Partially Done | Blocked

## Changed

- ...

## Acceptance Criteria

- AC1: Met | Not Met | Blocked - evidence

## Verification

- Command or scenario:
- Result:

## Human Check

- ...

## Risks

- ...