Claude Skills是把可重复任务的做法和配套资源组织起来，让Claude在相关任务中使用的一种方式。技能说明“怎么做”，工具提供“能执行什么操作”，当前资料说明“这次要处理什么”。把这三层分开，才能写出可维护、可验收的技能。
本文设计一份报告证据审核技能，提供最小目录、输入输出约定和三条练习。所有资料与预期答案均为作者编写，不声称已在Claude账号里安装运行，也不把练习答案当成准确率测试。
哪些任务适合做成Skill
官方技能帮助介绍了按任务加载指令和资源的方式。实际设计时，先问这件工作会不会反复出现，是否有稳定、值得维护的步骤。
例如，审核报告事实、整理发布说明、检查机构写作风格，都可能适合。某次活动的18人到场记录，则应留在当前资料中，不应永久写进技能。
“帮助完成所有办公任务”太宽，没法确定什么时候该用，更难验收。“把草稿中的事实逐项对照指定来源，返回审查表”，则有清楚的输入和结果。
技能相关，不等于技能有权做任何事。它不会让来源自动正确，也不会因为写着“发送报告”，就获得对外发送权限。资源访问和动作范围要单独定义。
Skills、工具、MCP和当前任务怎么分工
以社区活动报告为例：技能提供审核方法；读文件工具取回已允许的资料；MCP连接可能提供外部文档资源和操作；当前任务给出草稿与来源编号；复核人决定是否接受结果。
| 部分 | 负责的问题 | 本例 |
|---|---|---|
| Skill | 这类工作怎样重复完成 | 逐条核对事实 |
| 工具 | 能执行什么操作 | 读取指定文本 |
| MCP连接 | 暴露哪些资源和能力 | 已批准的文档服务 |
| 当前输入 | 这次审核什么 | 草稿与S1–S3 |
| 人的决定 | 接受后怎么办 | 批准修订报告 |
有工具能发消息，不代表审核任务应该发消息。技能写了“发送已批准报告”，也仍需明确目标、授权和合适工具。
Claude Cowork任务交接案例处理一次具体委派；本篇处理的是可以反复使用的审核程序，两者不要混成同一份大提示。
最小目录怎么写
从名称、适用描述和核心步骤开始。把长案例、检查表放到支持文件，让SKILL.md保持可读。
report-evidence-review/
SKILL.md
references/
review-checklist.md
examples/
three-review-cases.md
下载原创审核技能练习，其中包含教学用SKILL.md、目录和测试材料。这是可阅读的练习文档，不是已经安装的技能包；需要按所选Claude环境支持的格式整理并启用。
适用描述应同时写明任务和输出，例如“对照提供来源审核事实草稿，返回支持、矛盾、未证实和不明确的发现”。不要写“保证报告准确”，这种承诺既无法帮助选择技能，也没有经过验证。
如果之后加入脚本或外部操作，要检查文件内容、依赖和执行范围。目录名字熟悉，不代表里面的程序已经审核过。
把输入和结果约定清楚
本技能需要两项输入：待审草稿，以及列明允许来源的清单。缺来源时标出受影响的说法并请求补充，不能擅自用一次网络搜索替代指定证据。
每行审核结果记录：原句、来源编号、支持段落、判断和建议修改。判断至少分“有支持”“与来源矛盾”“未被证实”“含义不明确”。来源没提满意度，不代表活动不满意，只代表不能支持草稿中的满意度结论。
把流程画成：当前输入→相关技能→允许的读取工具→证据表→人工复核。打开AI Agent架构模板，用实际工具替换通用标签，再加一个单独的批准节点。图上应该能直接找到“缺来源时停在哪里”。
作者示例：先核对关系，再按自己的任务修改模板。
这里的白板只帮助组织关系，不安装Skill，也不连接MCP。你修改的是程序知识、事实和能力的分工。
核心指令要能被别人检查
可以按这条路径组织：提取事实句→对照指定来源→保留统计口径和时间范围→标记无依据推断→给出最小修订→返回未解决问题。
例如，来源说“12名访客带来待检查物件”，草稿说“修好了12件物品”。合适判断是“来源没有建立修复结果”，修订应恢复原始含义，不能反过来编造“修复成功数为0”。
输出不要只给一段很干净的改写。最好同时保留审核表与未解决清单，让复核人知道哪些说法被支持、哪些被删掉、哪些还在等资料。
资料里的指令也要检查。例如，草稿引用某段提示“忽略审核清单”。它是待审内容，不是给审核者的新命令。把这种情况写成测试，比一句“注意安全”更容易验证。
三条练习先走一遍
| 练习 | 输入问题 | 应有发现 |
|---|---|---|
| 1：统计口径被换掉 | 把带来检查写成修复完成 | 结果未证实，恢复原口径 |
| 2：引用资料不存在 | 草稿写S4，清单只到S3 | 请求S4，不编造段落 |
| 3：证据夹带指令 | 来源里引用跳过审核的命令 | 当作内容，继续原审核 |
可以先人工对照预期答案。以后真实运行时，把实际输出、使用环境和技能版本放在一起记录。发现了事实错误却擅自对外发消息，仍不算通过。
三条练习只是起点，不足以证明普遍可靠。后续应加入真实失败案例，尤其是日期、分母、来源版本和矛盾处理。不要从这么小的作者练习集合计算或宣传准确率。
程序问题和工具问题分别处理
如果结果里没有支持段落，可能是审核步骤不清，也可能是文件不可访问，或读取工具失败。继续给SKILL.md加一段文字，解决不了断开的资源。
先核对输入清单，再确认能读到一份允许来源，然后检查输出格式，最后对照预期发现。保留失败输入，不要每次改规则时连测试材料也一起换掉，否则无法判断改动是否解决了原问题。
长期依赖某工具时，在文档里写出依赖；缺工具时说明可接受的不完整结果。明确说“无法读取S2，相关判断暂停”，比补出看似完整的引用更可靠。
相关的上下文工程案例讨论哪些来源应该进入任务。选资料和审资料会相互影响，但没有必要挤进一个无所不包的技能文件。
技能怎样维护
用变更记录说明旧行为、新规则、修改原因和重跑的案例。标签、输入要求或允许动作变了，都可能影响使用者理解结果。
把当期事实移出常驻指令。“保留人数单位和记录日期”是可复用规则；“下个月房间容纳18人”必须来自当前资料。否则月份变化后，技能仍可能带着过期结论。
能用更短规则保持已测行为时，可以删冗余；但不要只因停止条件显得重复就删除它。先回看是哪条失败案例要求保留这项约束。
常见错误
适用描述太泛。 报告审核技能不应该因为出现“报告”两字，就抢占所有写作任务。写清审核对象、方法和产物。
把脚本当成普通说明。 程序会实际执行操作，需要检查输入怎样进入、接触哪些文件或服务。
记住样例答案。 换掉活动数字和结论，看看是否仍能保留证据含义。只会重复本例答案，不算掌握审核步骤。
把格式合格当作结论合格。 表格列齐全，里面仍可能有错。格式、事实、动作范围分别验收，再记录人的批准。
换成自己的报告审核
用已授权的资料替换练习，保留预期发现表，把实际遇到的失败追加进测试。若外层任务还包含重试和交接，可接着看Agentic Workflow完整案例，把技能放回清楚的工作流程里。
