Leroy
d3e9bd45bd
- SKILL.md 双工作流（创建/迭代）+ 两道门（验料/通用化）+ 三档位 - 7 篇方法论 references + 3 个纯标准库脚本（scaffold/validate/trigger_eval） - 自身触发用例 16 条 + 先例研究/创建/迭代证据报告 - 方法论吸收自 qiaomu-meta-skill 与 luban-skill，取舍见 reports/prior-art.md
74 lines
2.3 KiB
Markdown
74 lines
2.3 KiB
Markdown
# 交付报告——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` 结果
|
||
- 触发测试结果（冒烟 + 实测；实测没做就写「实测证据缺失」）
|
||
- 已知的用例失败项
|
||
- 刻意排除的职责
|
||
|
||
## 紧凑模板
|
||
|
||
```markdown
|
||
已交付：<skill>（<档位>）— <一句话职责>，装在 <路径>
|
||
|
||
参考学习
|
||
- <候选A>：学到 <机制>；落在 <位置>。
|
||
- <候选B>：学到 <机制>；落在 <位置>。
|
||
|
||
取舍与原创
|
||
- 保留：… / 改造：… / 舍弃：…（理由）/ 原创：…
|
||
|
||
亮点与证据
|
||
- [设计优势] …
|
||
- [已验证] …
|
||
- [假设] …（证据缺失）
|
||
|
||
验证：体检 <PASS/WARN…>；触发 <n/n>；实测 <结果或缺失>
|
||
边界：<不做的事、已知失败项>
|
||
```
|
||
|
||
## 诚实条款
|
||
|
||
- 「证据缺失」是合法状态，写出来不丢人，编造验证才丢人。
|
||
- 计划中的工作不是证据。
|
||
- 分数是预估就标"预估"，跑过实测才能去掉标注。
|