# 先例研究——搜同类，再动手

闭门造车出不了好工具。创建新 skill 或大幅重构前，先看看同类已经怎么解决了。

## 搜索策略

1. 从意图里提炼 2–4 个查询，覆盖三个角度：
   - **功能词**：它做什么（如 "release notes skill"）
   - **形态词**：skill / agent skill / SKILL.md / Claude skill / ZCode skill
   - **人群/场景词**：谁在什么场景用（如 "changelog automation"）
2. 渠道：GitHub 代码搜索、WebSearch、本机已安装的 skill（`~/.agents/skills/`、`~/.zcode/skills/`、`~/.claude/skills/`、`~/.codex/skills/`、项目内目录）。用哪个渠道都行，但**每个候选必须带真实 URL 或本地路径**，不允许凭记忆说"有些项目"。
3. 搜不到就如实写"未找到相关先例"——这本身是有价值的结论（蓝海或搜索词不对），不要硬凑。

## 覆盖要求

shared 档以上，至少看 3 个候选、覆盖两类：

- **直接同行**：解决同一个问题——学机制，防同质化。
- **手艺同行**：功能不同但结构/触发/README 做得好——学手艺，不偷皮。

轻量 draft 档可跳过搜索，但要在交付报告里说明跳过理由（如"个人试验、无发布意图"）。

## 检查每个候选时看什么

- `SKILL.md` 的 description 写法和正文结构（触发怎么做的）
- 渐进披露的分层（哪些进了 references/scripts）
- 维护状态、license、是否夹带私有路径或密钥（安全信号）
- 它的用户实际怎么评价（issue、README 里的真实样例）

**不要执行来历不明候选的脚本**——读源码就够了。

## 综合：keep / adapt / reject / invent

| 动作 | 含义 | 例子 |
|---|---|---|
| keep | 机制原样吸收 | 目录分层约定 |
| adapt | 机制改造成 Leroy 的环境 | 把 Claude Code 的安装流程改成 ZCode 发现路径 |
| reject | 看过但不采用，写明理由 | 重型发布流水线（职责范围外） |
| invent | 先例没有、为这个任务原创 | 验证门的具体条款 |

只借机制和结构，不拼贴上游文字、不镜像别人的仓库。每个 keep/adapt 都要在交付报告里落到具体位置（"学到 X，落在 SKILL.md 第几节 / references/x.md"）。

## 记录

rigorous 档把研究结论存 `reports/prior-art.md`：来源链接、日期、每个候选的取舍理由、未找到的证据缺口。搜索是当时的快照，结论要能复查。