菜单
开始实现某一个 backlog 条目。独立诊断、重新思考方案、协助从 backlog 移除或重写条目。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | backlog-implement |
| description | 开始实现某一个 backlog 条目。独立诊断、重新思考方案、协助从 backlog 移除或重写条目。 |
从 backlog 中选取一个条目，独立诊断问题，重新思考方案，引导用户完成实现，最终协助清理或重写 backlog。
Implementer Agent — 负责把 backlog 中的延后项落地为代码改动。Agent 是问题的重新审视者，不是条目字面意思的执行者。
用户可直接提供 backlog ID，或仅调用技能让 Agent 展示列表供选择：
/backlog-implement B-260506-a3f9c1
/backlog-implement # 无参数，展示列表供选择
按三个阶段执行：独立诊断 → 对齐与确认 → 实施。
阶段 B 为强制门禁——未经用户明确确认，禁止进入阶段 C 修改任何代码。
核心原则：backlog 条目是某人在某时刻的快照。Agent 拿到条目后，第一反应是重新验证，不是按图索骥。
获取条目：
python docs/agent/tools/backlog.py show <id>
python docs/agent/tools/backlog.py list
独立诊断——不止核实现象，更要主动重新审视：
产出是 agent 对这个问题的重新理解，可能和原条目一致，也可能差很多。
可选：质疑条目——独立诊断后，若发现条目本身有问题，提出对应动作（不擅自执行，只提议）：
backlog-check 关闭流程向用户输出三栏式汇报，自由组织内容，不必死板照抄：
我看到了什么:
<agent 独立诊断的结果，不一定与 backlog 描述一致>
<如发现新代码路径、新症状、新线索，在此说明>
我建议怎么做:
<agent 独立想出的方案，不必基于「开发备忘」字段>
<如对比原方案，说明差异和取舍>
需要你拍板的:
<真正不确定的地方>
<不要把所有细节都列给用户——只列 agent 自己无法决定的部分>
「需要你拍板」这一栏是关键。它强迫 agent 区分「我可以决定」和「需要你决定」，而不是把所有东西都推给用户。
门禁规则：未收到用户明确确认（如"可以""开始""没问题"等），禁止进入阶段 C。用户提出修改意见时，回到上方更新方案后再次等待确认。
环境隔离（用户要求时）：
若用户要求 worktree 隔离，必须调用 start-feature 技能创建独立工作区，禁止裸调 EnterWorktree。start-feature 会输出 worktree 路径并施加路径硬约束，避免后续所有文件操作误写到原始仓库。
实施：
review0-walkthrough 或 opsx:new 创建独立变更流程，本技能等待其结果。测试与验证：
修改完成后跑项目配套测试（uv run pytest 或相关模块测试），确认不破坏现有功能。
清理 backlog： 实现并测试通过后，向用户确认是否从 backlog 移除该条目。 用户确认后：
python docs/agent/tools/backlog.py close <id>
若实施中提议了「重写条目」，可一并更新 backlog 内容（用 Edit 工具修改对应条目段落）。
汇报：
Backlog 条目实施完成
- ID: B-...
- 标题: ...
- 改动范围: ...（文件/函数摘要）
- 独立诊断与原条目差异: ...（如有）
- 已从 backlog 移除 / 已重写 backlog: 是
使用 DicePP Shell 工具进行交互式机器人指令验收。涉及用户可见指令、骰子结果、会话状态、多步骤流程、私聊/群聊差异或需要确认机器人实际回复时使用；开发验证时可由 auto-test-run 配合调用。
运行 DicePP Persona 真实 LLM 功能回归，客观验收生活模拟、主动消息、私聊多轮、群聊上下文、持久化和 trace。仅在用户显式调用本技能或明确要求 Persona 真实 LLM 回归时使用；不得自动触发，也不得由 subagent 自行调用。
代码审视清理——扫描变更中的遗留调试代码、废弃注释、无 backlog 引用的 TODO 等，一次确认后批量修改，跑通全量测试。
用当前 dev 源码在 5090 端口起一个 Dashboard 实例(默认仅本地 127.0.0.1,--expose 才绑 0.0.0.0),联动 dicepp-shell serve 常驻 Bot Runtime,做 Dashboard 开发联调验收。需要可视化 Dashboard 状态、调试控制通道、验证 Bot↔Dashboard 通信、测试 Dashboard 面板与真实 Bot 生命周期联动,或要在不碰生产 docker 栈的前提下用 --expose 临时把 Dashboard 暴露给外网查看时使用。
从 master 创建新的 feature 分支，基于 git worktree 实现环境隔离。
开发分支提交重组——分析、分组、walkthrough 确认、reset-soft 重提交、验证无内容丢失。不修改代码。