| name | fix-todo |
| description | 从已提交的 todo 文件（todo.not / TODO.md 等）读取待办条目，在当前分支原地自主修复，每个条目一个 commit 并把对应条目移入"已解决"节。当用户要求修复 todo 里的问题、处理待办列表，或调用 /fix-todo 时使用。想在 herdr worktree 里派独立 agent 执行时用 fix-todo-herdr。 |
fix-todo
核心契约：一个修复 commit = 代码 + 测试 + todo 条目移动。条目从待办节移入已解决节与代码改动同 commit，git 历史即为 changelog。
本 skill 是当前检出、当前分支上的原地操作，自己不做 worktree 隔离。想把修复隔离到 herdr worktree 并派独立 agent 执行，用姊妹命令 fix-todo-herdr（编排层，内部最终也是让一个 agent 执行本 skill）。
前置检查（不满足则中断）
- 发现 todo 文件：按序探测
todo.not、docs/todo.not、TODO.md、todo.md；多个命中时问用户选哪个。
- 只读已提交版本：
git show HEAD:<path>，不读工作区副本。
- 文件未被 git 跟踪（git show 失败）→ 提示用户先提交该文件，中断。
- 已提交版本中待办节为空 → 报告"没有待办条目"，中断。
- 工作区副本与 HEAD 不一致 → 警告"工作区有未提交改动，将被忽略"，继续执行。
- 列出本次覆盖的条目清单（编号 + 首行文本），输出后直接开干，不等确认。用户可用参数筛选子集（如
/fix-todo #parse、/fix-todo 1 3）。
条目与文件结构约定
- 文件恰好一个待办节和一个已解决节；已解决集中一处（内部子章节、tag 组织随意）。
- 节标题按关键词识别：待办 =
待办 / 存在问题 / Open / TODO；已解决 = 已解决 / Resolved / Done。文件缺已解决节时创建之。
- 条目 = 节内顶层列表项；首行是标识文本（用于展示与
git log -S 反查），缩进的复现示例、讨论随条目一起移动。
- 语言特定形态：
- notist：
== 存在的问题 / == 已解决；条目 #[描述]@#tag；解决时条目追加 @date="yyyy-mm-dd"（字符串字面量，postfix 标注，已验证可解析）；
- markdown：
## Open / ## Resolved；普通 bullet；解决时追加 (resolved: yyyy-mm-dd)。
- 日期取执行时环境（
date +%F），不要猜。
执行流程
- 诊断可并行：可并行派子代理做各条目的根因定位，但落地串行——所有修复按顺序提交到当前分支。
- 逐条目修复：先写复现失败的测试 → 修复 → 跑测试 → commit。commit 内容 = 代码 + 测试 + todo 条目移动（从待办节删除，附日期追加到已解决节）。message 沿用仓库既有风格（先
git log --oneline 观察），body 带一行 Todo: <条目首行原文> 供 git log --grep 反查。条目不写 commit hash——hash 无法写进自身所在 commit（自引用），且 squash 后会悬空。
- 遵守仓库 AGENTS.md 的资源约束（如本机 cargo 需
cargo test -j4 -- --test-threads=4）。
- 修不了的条目：不移动、不假装完成，记录原因并在汇报中说明。
- 范围外新发现的 bug：不顺手修，追加到当前检出的 todo 文件待办节（工作区改动，不单独提交），并在汇报中提及。
- 收尾：逐条目汇报根因（文件:行号）、修复方式、commit hash、测试结果。
可追溯性
追溯不依赖条目文本里的 hash，靠两个 squash/rebase 免疫的机制：
git log -S "<条目文本>" -- <todo文件>：条目移动必然包含该文本的增删；- commit body 的
Todo: 行：git log --grep 可查。
