skill-factory
如同细心的维护者一样构建技能，然后等待用户批准后再发布。适用于任何智能体；每个步骤都会指明最佳工具及一个始终有效的备用方案。
输入：一个技能创意，或由loot交出的附带证据（查询、搜索结果、证明、边缘情况）的掉落物。目标文件夹：用户指定的位置，否则位于当前仓库历史之外的../<slug>。
1. 规格说明
编写SPEC.md：目标、输入和输出，以及一个每行都可测试的验收清单。控制在一页以内。如果loot已交出该项，则重用其证据，避免再次搜索。仅当对创意有两种解读会导致不同技能时，才询问用户。
2. 构建，测试先行
- 如果智能体有技能编写助手（在Claude Code中：
anthropic-skills:skill-creator），则使用它来创建技能及其评估。 - 否则自行编写
SKILL.md：包含name（kebab-case格式）和description（说明功能及触发时机）的前置信息，然后是步骤。 - 脚本在代码之前先编写测试（使用
node:test或pytest）。实现代码直到测试通过。使用文件编辑工具编写文件，而不是shell heredoc。 - 运行所有测试和评估。保留确切的命令及其输出，用于步骤4。
3. 独立审查
构建者不评判自己的工作。
- 最佳方式： 启动一个未见过本对话的子智能体。仅向其提供目标文件夹和
references/release-checklist.md，并附上以下简要说明：“请对照清单审查<文件夹>中的技能。每项回答PASS或FAIL，并附带文件：行证据。不确定时，选择FAIL。标记任何测试或评估未证明的主张。” - 备用方案： 无子智能体：对于清单中的每一项，先写出它FAIL的最有力论据，再做出决定。
修复所有FAIL，重新运行测试，再次审查。当所有项目通过，或某项因用户而受阻（说明是哪项及原因）时停止。
4. 发布关卡
扫描密钥：node <loot技能文件夹>/scripts/scan.mjs <文件夹>，如果安装了gitleaks，则运行gitleaks dir <文件夹>。然后向用户展示清单并等待明确的是：
- 仓库名称，公开或私有
- 版本号和更新日志条目
- 要发布的文件
- 测试和评估结果（命令 + 通过数量），审查结论
- 任何跳过的内容
一个“是”仅针对该清单。然后从全新的git init开始发布：提交release vX.Y.Z，打标签，gh repo create并推送，并在用户智能体加载技能的路径中安装该技能。如果没有gh或未登录，则打印命令。绝不询问、输入或存储凭据。
5. 报告
用简明语言发送一条简短消息：链接、测试结果、审查结果，以及留给用户处理的事项。