- SKILL.md 双工作流(创建/迭代)+ 两道门(验料/通用化)+ 三档位 - 7 篇方法论 references + 3 个纯标准库脚本(scaffold/validate/trigger_eval) - 自身触发用例 16 条 + 先例研究/创建/迭代证据报告 - 方法论吸收自 qiaomu-meta-skill 与 luban-skill,取舍见 reports/prior-art.md
2.3 KiB
2.3 KiB
交付报告——handoff 怎么写
创建或大幅修改 skill 后,用这个结构交付。报告要短到能在最终回复里读完,rigorous 档同步存 reports/creation-handoff.md(或 iteration-<日期>.md)。
报告结构
1. 结果
- skill 名、档位、一句话职责
- 安装路径
- 本次做了什么(创建 / 迭代了哪个面)
2. 参考学习(做了先例研究时)
列出 2–4 个真正看过源码的候选(搜索结果里瞥过一眼的不算):
- 名称 + URL/路径
- 为什么入选
- 学到的具体机制
- 该机制落在新 skill 的哪个位置
3. 取舍
- 保留:原样吸收的机制
- 改造:为 Leroy 的 runtime 环境(ZCode/Claude Code/Codex)改过的机制,写怎么改的
- 舍弃:看过但没采用,写具体理由
- 原创:先例没有、这次新造的
4. 亮点与证据
每个亮点三选一标注,不许裸奔:
| 标签 | 含义 | 允许的说法 |
|---|---|---|
[设计优势] |
源码里看得见的设计选择 | "相比看过的候选,本包显式做了 X" |
[已验证] |
有触发/输出/实测证据支撑 | "触发用例 8/8 通过(reports/trigger-eval.json)" |
[假设] |
合理但未证明 | "预期能减少误触发,但缺实测证据" |
不写"最好""比 X 强"——没有公平对比就不许下比较级结论。清单差异不等于效果优势。
5. 验证与边界
validate_skill.py结果- 触发测试结果(冒烟 + 实测;实测没做就写「实测证据缺失」)
- 已知的用例失败项
- 刻意排除的职责
紧凑模板
已交付:<skill>(<档位>)— <一句话职责>,装在 <路径>
参考学习
- <候选A>:学到 <机制>;落在 <位置>。
- <候选B>:学到 <机制>;落在 <位置>。
取舍与原创
- 保留:… / 改造:… / 舍弃:…(理由)/ 原创:…
亮点与证据
- [设计优势] …
- [已验证] …
- [假设] …(证据缺失)
验证:体检 <PASS/WARN…>;触发 <n/n>;实测 <结果或缺失>
边界:<不做的事、已知失败项>
诚实条款
- 「证据缺失」是合法状态,写出来不丢人,编造验证才丢人。
- 计划中的工作不是证据。
- 分数是预估就标"预估",跑过实测才能去掉标注。