Leroy
d3e9bd45bd
- SKILL.md 双工作流（创建/迭代）+ 两道门（验料/通用化）+ 三档位 - 7 篇方法论 references + 3 个纯标准库脚本（scaffold/validate/trigger_eval） - 自身触发用例 16 条 + 先例研究/创建/迭代证据报告 - 方法论吸收自 qiaomu-meta-skill 与 luban-skill，取舍见 reports/prior-art.md
46 lines
2.4 KiB
Markdown
46 lines
2.4 KiB
Markdown
# 先例研究——搜同类，再动手
|
||
|
||
闭门造车出不了好工具。创建新 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`：来源链接、日期、每个候选的取舍理由、未找到的证据缺口。搜索是当时的快照，结论要能复查。
|