| name | duxing |
| description | 笃行 (Duxing) — earnest execution: clarify once, build, verify. 开发任务管线：需求先按做错成本分档，轻档直接做完自查交付；重档走 事实挖掘→一次性澄清→规格卡→实现→独立验证→沉淀。触发词：duxing、笃行、"按笃行流程做"，或用户交给你一个功能需求 / bug fix 开发任务时。 |
笃行 Duxing — 澄清一次，做完自证
博学之（事实挖掘）、审问之（一次澄清）、慎思之（问题分诊）、明辨之（独立验证）、笃行之（实现）。
核心原则
- 澄清最多一轮。 能从代码库和约定库查到的，一律不问；问就必须自带推荐答案。
- 流程重量与做错成本成正比。 低风险直接做，做错了用户提意见再改。
- 三方分离。 实现者、验证者、定标准者是三个独立角色（独立子代理、干净上下文）。
- 证据铁律。 新鲜执行的命令输出、exit code、diff 才算证据；"应该没问题"、旧的运行结果、子代理自报的成功，都不算。
- 给人看的只讲产品逻辑。 功能、交互结果、异常处理三件事；实现细节不进卡点文档。
- 只沉淀经验证成功的经验，且蒸馏成原理。 记"为什么"，规则只是实例。
第 0 步：风险分档
命中任一条即重档，否则一律轻档：
- 不可逆或高代价：涉及资金、交易、数据删除、对外发布；
- 方向未定：存在多种合理产品方案，选错要整体重做；
- 跨模块的新功能，或引入新的外部接口/依赖；
- 用户明确要求走完整流程。
拿不准按轻档——先做出一版直观的东西给用户看。禁止为小改动举行仪式（改按钮颜色不需要需求文档）。
轻档路径
实现 → 自查（review diff、跑相关测试、实际触发一次改动路径）→ 交付时一句话说明行为变化。有值得沉淀的经验则执行第 7 步。
重档路径
1. 事实挖掘
- 读
.duxing/conventions/INDEX.md，展开与本任务相关的约定正文；
- 用 Explore 子代理搜代码库：类似实现、公共组件、既有交互模式；
- 起草规格时，任何没有依据的假设必须内联标记
[待澄清: 具体问题]，禁止脑补。
2. 问题分诊
对每个 [待澄清] 标记归类：
- A 类：代码有先例 → 沿用先例，消除标记；
- B 类：通用工程实践（防抖、输入校验、错误提示等），或约定库原理可推导覆盖 → 按默认做，消除标记；
- C 类：真正的业务决策——必须能写清**"为什么代码回答不了它"**，写不清就降为 B 类。
3. 一次性澄清（存在 C 类时）
所有 C 类打包成一轮提问。每题必须附基于事实的推荐答案，让用户可以只回一句"按默认"。此后整个任务不再追问。
4. 规格卡 → .duxing/specs/<任务名>.md
由独立的定标准子代理产出，输入只有事实清单 + 澄清结论。文件结构：
# <任务名>
Status: DRAFT | CONFIRMED | BUILDING | VERIFYING | DONE
## 产品逻辑（给人看，10 秒读完）
1. 做完后达成什么功能
2. 用户做什么操作 → 出什么结果
3. 错误、异常如何处理
## 验收断言（编号，EARS 单句）
- A1. WHEN <触发条件> THE SYSTEM SHALL <单一可观察行为>
Verify: <验证它的具体命令或操作>
- A2. IF <异常情况> THEN THE SYSTEM SHALL <响应>
Verify: ...
## QA Results（仅验证者可写）
断言写法：一句一断言，只描述可观察行为，禁止"应当合理处理"之类的散文。给用户确认的只有"产品逻辑"三段；确认后 Status → CONFIRMED 动工。
5. 实现
对照断言编号实现。实现者不许增删改断言——发现断言有误就停下回报，不许悄悄改成自己能通过的样子。通用实践直接做进去，不在交付说明里反复强调。
6. 独立验证
派全新验证子代理，执行本 skill 目录下 references/verifier.md 协议。输入只给：规格卡路径 + diff 范围，不给实现过程的任何对话。
- 验证者逐条核销断言，把结果和证据写入规格卡 QA Results 区；
- 总判定枚举：PASS / CONCERNS / FAIL；
- FAIL 或 CONCERNS → 实现者针对 gap 清单修复 → 重验，最多 3 轮；
- 3 轮不过，停止原地重试：换干净上下文重做实现，或如实升级用户。验证者的发现是 gap 清单，不是一票否决——实现者认为某条是误杀时，向用户呈现双方依据。
7. 沉淀
- 澄清得到的答案、验证通过后的经验 → 蒸馏成约定写入
.duxing/conventions/<主题>.md（格式：触发条件 / 原理 / 实例 / 关联），并在 INDEX.md 加一行索引。只沉淀经验证成功的做法，且必须去具体化：参数抽象成变量，场景抽象成触发条件，让原理能推广到新场景。
- 可复用的验证脚本 →
.duxing/verify/，纳入后续任务回归集。
- 交付报告末尾用一两行列出"本次沉淀了什么"，用户可否决。
.duxing/ 变更提交 git。
.duxing/ 目录结构
.duxing/
conventions/
INDEX.md # 每条约定一行：触发条件摘要 → 文件名（常驻索引，正文按需展开）
<主题>.md # 触发条件 / 原理 / 实例 / 关联
specs/ # 规格卡（Status 字段即任务台账，跨会话可恢复）
verify/ # 可复用验证脚本，回归资产
