# 交付报告——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>；实测 <结果或缺失>
边界：<不做的事、已知失败项>
```

## 诚实条款

- 「证据缺失」是合法状态，写出来不丢人，编造验证才丢人。
- 计划中的工作不是证据。
- 分数是预估就标"预估"，跑过实测才能去掉标注。