/x-dev

name: x-dev
description: |
  开发任务执行 skill。读取单个 task 的 dev-checklist.md，按行序以"先测试后实现"的方式逐行执行，dev-report 只记验证结论（全绿或 N 个 🔴），全部行验证通过后交付。触发：`x-dev {task-dir}`、用户要求执行/开发某个 task。

x-dev — task 执行

输入与边界

x-dev 的作用域是**单个 task**：`docs/spec/<spec-name>/tasks/<task-name>/`，入口是它的 `dev-checklist.md`，按头部 `spec:` 指针跟读 v6 spec 的相关 feat 与场景。一个 spec 下可以有多个 task，x-dev 一次只执行指定 task，不扫描或编排同级 task。

checklist 的约定（由 x-req 生成）：

• **行序即实现顺序**，无依赖图；从 T1 开始逐行往下做。
• **场景回指定验收**：一行做完的判定标准是它回指的每个场景的 GIVEN/WHEN/THEN 全部成立。
• **风险列为 `高:` 的行**，验证必须包含真实链路（smoke 或以上），不允许只写 unit。
• 改动落在「涉及文件」范围内，不"顺便"改别的。

执行

高能力模型按批次执行：独立读取放同一批次；文件只在内容变化后重读；过程更新只报告新进展或阻塞。

1. **取证批次**：一次读完整 checklist、spec 中被回指的 feat 场景、涉及的实现与测试文件，建立「场景 → 代码 → 测试」的对应关系；顺带确认涉及文件路径真实存在（x-req 留了 glob 的就在此批次定位）。 2. **逐行 TDD**（先测试后实现，顺序不能反）：

• 把当前行状态改为 `[ ] ▶️`。
• 为行回指的场景写测试：场景的 THEN 就是断言。先跑一遍，确认失败原因是"功能还没实现"。
• 写实现，改动保持在涉及文件范围内，让测试变绿。
• 测试通过后行状态改为 `[x] 🟢`。测试照常真实运行，但输出不写进文档。

3. **行失败时**：读完整输出，按根因一次修完全部关联位置；发现是测试写错就改测试并在 dev-report 未决节记一行原因。同一行失败多次不改目标——回看场景定义，仍不清楚就停下来问用户。失败中的行标 `[!] 🔴`，修复后恢复。 4. **收尾验证**：全部行 🟢 后，跑一次本 task 全量测试 + 一次既有测试回归（确认没有破坏 spec 概述和既有功能里的不变量），把结论（全绿 / N 个 🔴、回归通过与否）记进 dev-report。 5. **交付**：确认 checklist 无 🔴 残留，输出回执，报告下一步（同 spec 的下一个 task，或全部完成）。

dev-report

`docs/spec/<spec-name>/tasks/<task-name>/dev-report.md`，只记结论、不贴测试输出：全绿或 N 个 🔴、回归结果、高风险行验证情况；红色失败一行一条摘要。完整读取 `templates/dev-report.md` 后填充。

自检（交付前）

• checklist 每个非 `None` 场景回指都有对应测试且行状态 🟢？
• 高风险行有真实链路验证？
• 全部改动都在「涉及文件」范围内？
• 既有测试回归通过？
• 每个 🔴 行都在 dev-report 未决节有一行摘要？

回执

✅ x-dev 完成 · <task-name> · 行 N/N 🟢 · 场景覆盖 M/M · 高风险行 K（已验证）· 回归通过

有阻塞或失败残留时如实列出：行号、失败摘要、已尝试的动作、需要用户决定的问题。