Leroy
d3e9bd45bd
- SKILL.md 双工作流（创建/迭代）+ 两道门（验料/通用化）+ 三档位 - 7 篇方法论 references + 3 个纯标准库脚本（scaffold/validate/trigger_eval） - 自身触发用例 16 条 + 先例研究/创建/迭代证据报告 - 方法论吸收自 qiaomu-meta-skill 与 luban-skill，取舍见 reports/prior-art.md
2.4 KiB
2.4 KiB
先例研究——搜同类，再动手
闭门造车出不了好工具。创建新 skill 或大幅重构前，先看看同类已经怎么解决了。
搜索策略
- 从意图里提炼 2–4 个查询，覆盖三个角度：
- 功能词：它做什么（如 "release notes skill"）
- 形态词：skill / agent skill / SKILL.md / Claude skill / ZCode skill
- 人群/场景词：谁在什么场景用（如 "changelog automation"）
- 渠道：GitHub 代码搜索、WebSearch、本机已安装的 skill（
~/.agents/skills/、~/.zcode/skills/、~/.claude/skills/、~/.codex/skills/、项目内目录）。用哪个渠道都行，但每个候选必须带真实 URL 或本地路径，不允许凭记忆说"有些项目"。 - 搜不到就如实写"未找到相关先例"——这本身是有价值的结论（蓝海或搜索词不对），不要硬凑。
覆盖要求
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：来源链接、日期、每个候选的取舍理由、未找到的证据缺口。搜索是当时的快照，结论要能复查。