Skills
Standards
本站对 skill 质量的最小统一标准
本站当前采用的 skill 标准来自三类来源的交集：
agentskills.io的创建最佳实践agentskills.io的描述优化与评估思路- 本仓库自己的 TDD / verification / review 纪律
Pass Bar
一个 skill 在本站至少要过这条线：
- 能说清楚什么时候触发，什么时候不该触发
- 有默认流程，不把用户扔进菜单式分支
- 有验证循环，说明如何确认输出真的合格
- 有失败处理，不在失败时继续假装成功
- 有 eval 资产，至少覆盖正例和反例
Evaluation Layers
本站把 evaluate 拆成两层：
evals/queries.json关注 Trigger Precision 和 False Positivesevals/evals.json关注 skill 被触发后，输出是否满足最小质量线
这两层一起看，才能避免：
- 该触发时不触发
- 不该触发时乱触发
- 触发了但输出只是“看起来像在工作”
Rubric
| 维度 | 要求 | 最低过线标准 |
|---|---|---|
| Trigger Precision | 触发条件清楚，能覆盖真实用户说法 | 至少有 2 个正例，且描述不是空话 |
| False Positives | 不该触发的场景能明确排除 | 至少有 1 个反例 |
| Default Path | skill 有默认执行路径 | 能按顺序执行，不需要二次猜测 |
| Verification Loop | skill 说明如何验证自己是否做对 | 至少有一轮“执行后再检查”的闭环 |
| Failure Handling | 失败时怎么收敛 | 不会在失败时继续给高置信结论 |
| Output Contract | 输出结构稳定，可被 review | evals/evals.json 能验证关键输出项 |
Review Checklist
给 skill 做 review 时，至少过一遍这 6 项：
description是触发条件，不是流程摘要SKILL.md里有触发条件 / 前置条件 / 默认流程 / 验证循环 / 成功判据 / 失败处理queries.json同时包含正例和反例evals.json能检查关键输出，不只是检查关键词- skill 不会把假设说成已确认事实
- skill 的默认路径足够窄，不会偷偷扩大范围
Common Failure Modes
下面这些情况，默认都算没过线：
description太泛，像口号，不像触发器- 只有“做什么”，没有“怎么验证”
- 只有正例，没有反例
- skill 会在信息不足时给高置信结论
- 失败处理只写“重试”而没有收敛路径
- 结构看起来完整，但默认流程根本无法执行
Current Policy
当前本站要求重点 skill 同时包含：
evals/queries.jsonevals/evals.json- 可复用的默认流程
- 可复用的验证循环
前者判断“该不该触发”，后者判断“触发后输出是否合格”。
Risk-tier Compatibility
如果一个 skill 会参与高风险任务，它还必须说明：
- 什么时候应该进入 Guarded Path
- 什么时候需要 Preflight
- 什么时候不能直接放行
Human Trust Compatibility
如果 skill 影响的是 agent-authored 结果的放行，它必须说明：
- 低风险时哪些证据足以放行
- 高风险时什么情况下必须人工验收
- 什么时候应该输出
needs-human-acceptance