backlog-implement

name	backlog-implement
description	开始实现某一个 backlog 条目。独立诊断、重新思考方案、协助从 backlog 移除或重写条目。

backlog-implement — 实施 backlog 条目

从 backlog 中选取一个条目，独立诊断问题，重新思考方案，引导用户完成实现，最终协助清理或重写 backlog。

角色

Implementer Agent — 负责把 backlog 中的延后项落地为代码改动。Agent 是问题的重新审视者，不是条目字面意思的执行者。

参数要求

用户可直接提供 backlog ID，或仅调用技能让 Agent 展示列表供选择：

/backlog-implement B-260506-a3f9c1
/backlog-implement              # 无参数，展示列表供选择

流程

按三个阶段执行：独立诊断 → 对齐与确认 → 实施。

阶段 B 为强制门禁——未经用户明确确认，禁止进入阶段 C 修改任何代码。

---

阶段 A — 独立诊断

核心原则：backlog 条目是某人在某时刻的快照。Agent 拿到条目后，第一反应是重新验证，不是按图索骥。

1. 获取条目：

   • 若用户提供了 ID：

     python docs/agent/tools/backlog.py show <id>
     

   • 若无参数：

     python docs/agent/tools/backlog.py list
     

     展示列表，请用户选择一条（回复 ID 或序号）。

2. 独立诊断——不止核实现象，更要主动重新审视：

   • 问题表现字段：去代码里印证。症状描述准确吗？我看到的是不是和它写的一致？根因真的是它说的那个吗？
   • 开发备忘字段：仅作历史参考。agent 有权采纳、修正、或完全推翻。
   • 优先级 / 类型 / 改动量：agent 可以提出调整建议。
   • 还有没有条目没提到的相关代码路径、症状、影响面？

   产出是 agent 对这个问题的重新理解，可能和原条目一致，也可能差很多。

3. 可选：质疑条目——独立诊断后，若发现条目本身有问题，提出对应动作（不擅自执行，只提议）：

   • 关闭：症状已不存在 / 已被别的改动解决 / 改动意义不大 → 提议走 backlog-check 关闭流程
   • 重写：症状描述不全 / 根因错位 / 优先级/类型/改动量评估错误 → 提议重写条目（不擅自动条目）
   • 若只是诊断与原条目不一致但条目本身没大问题，直接在阶段 B 汇报差异即可，不需要走「重写」

---

阶段 B — 对齐与确认（强制门禁）

向用户输出三栏式汇报，自由组织内容，不必死板照抄：

我看到了什么:
  <agent 独立诊断的结果，不一定与 backlog 描述一致>
  <如发现新代码路径、新症状、新线索，在此说明>

我建议怎么做:
  <agent 独立想出的方案，不必基于「开发备忘」字段>
  <如对比原方案，说明差异和取舍>

需要你拍板的:
  <真正不确定的地方>
  <不要把所有细节都列给用户——只列 agent 自己无法决定的部分>

「需要你拍板」这一栏是关键。它强迫 agent 区分「我可以决定」和「需要你决定」，而不是把所有东西都推给用户。

门禁规则：未收到用户明确确认（如"可以""开始""没问题"等），禁止进入阶段 C。用户提出修改意见时，回到上方更新方案后再次等待确认。

---

阶段 C — 实施（用户确认后）

0. 环境隔离（用户要求时）： 若用户要求 worktree 隔离，必须调用 start-feature 技能创建独立工作区，禁止裸调 EnterWorktree。start-feature 会输出 worktree 路径并施加路径硬约束，避免后续所有文件操作误写到原始仓库。

1. 实施：

   • 按对齐的方案改代码。不以「开发备忘」字段为起点——方案已在阶段 B 独立提出。
   • 实施过程中按变化幅度分级处理：
     • 小调整（换实现方式、调整边界、改名）：直接做，简短告知
     • 方向性变更（解法变成另一个解法、scope 显著扩大/缩小）：停下来回到阶段 B
     • 条目本身需要重写（诊断推翻原条目结论）：提议重写条目，不擅自改 backlog
   • 简单改动（单文件、局部逻辑）：直接编辑代码。
   • 复杂改动（涉及多模块、需设计决策）：建议用户先走 review0-walkthrough 或 opsx:new 创建独立变更流程，本技能等待其结果。

2. 测试与验证： 修改完成后跑项目配套测试（uv run pytest 或相关模块测试），确认不破坏现有功能。

3. 清理 backlog： 实现并测试通过后，向用户确认是否从 backlog 移除该条目。 用户确认后：

   python docs/agent/tools/backlog.py close <id>
   

   若实施中提议了「重写条目」，可一并更新 backlog 内容（用 Edit 工具修改对应条目段落）。

4. 汇报：

   Backlog 条目实施完成
   - ID: B-...
   - 标题: ...
   - 改动范围: ...（文件/函数摘要）
   - 独立诊断与原条目差异: ...（如有）
   - 已从 backlog 移除 / 已重写 backlog: 是
   

约束

• 阶段 B 门禁为硬约束：未经用户明确确认，禁止修改任何代码。诊断完毕但用户未确认 → 等待，不得跳过
• 不自动 commit 或 push（受全局规则约束）
• 不擅自修改 backlog 文件——关闭/重写/重分类等动作都需先经用户同意
• 重新诊断不限制自由度——agent 可质疑条目本身、可推翻原方案、可调整 scope；遇到方向性变更时回到阶段 B 重新对齐
• 复杂改动必须走独立设计流程，不得在本技能内直接开搞大重构
• 清理 backlog 前必须完成测试验证