并不是所有指令都需要封装成Skill。优质的Skill应当具备**"高频复用"、"流程复杂"或"上下文依赖强"**的特征。所以第一步是弄清楚什么任务该打包成skill，可以从下面这几个维度去衡量评判：
| 任务类型 | 特征描述 | 典型示例 | 封装建议 |
|---|---|---|---|
| 标准化SOP | 步骤固定、逻辑严密的任务 | 代码审查、生成单元测试、发布Release Note | 推荐封装 |
| 跨工具协作 | 需要组合调用多个工具才能完成的任务 | 搜索+阅读+总结 | 推荐封装 |
| 特定领域知识注入 | 需遵循特定团队规范、代码风格或业务逻辑 | 团队代码规范、业务逻辑检查 | 推荐封装 |
| 避免过度封装 | 简单的单步操作 | 帮我格式化这段代码 | 无需封装（直接对话即可） |
一、诸多提升质量的技巧
（1）把 description 写成触发器
description 是 Agent 路由判断是否调用该 Skill 的唯一依据，必须包含用户可能使用的高频动词和名词，同时简要说明该 Skill 不做什么，防止误触发。
差： "代码检查"
优： "执行代码审查、Lint 检查、发现代码异味及提供优化建议（不执行代码重构）"
（2）正文用编号步骤写SOP
LLM 对结构化指令的遵循度远高于大段文本，应将任务拆解为不可再分的原子动作，并在步骤中嵌入思维链与条件分支。
- 原子化步骤： 将任务拆解为不可再分的原子动作。
- 思维链引导： 在步骤中嵌入思考过程。例如："1. 首先分析用户意图；2. 检索相关文档；3. 根据文档生成回答。"
- 条件分支： 使用"如果...则..."的逻辑，指导模型在不同情况下的行为。
执行步骤
读取用户提供的开发模块、完成度、阻塞点。
如果有表格数据，先提取关键字段。
按"今日进展 / 明日计划 / 风险阻塞"三段式生成日报。
如果信息不足，先追问缺失字段。
（3）明确输出格式
不要让模型猜测你想要的结果样子。
指定结构： 明确要求输出为 Markdown 表格、JSON、代码块或特定的列表格式。
模板化： 在Skill中直接提供一个输出模板，让模型填空。
（4）提供正反示例
Few-shot prompting 是提升效果最显著的手段之一。
正例： 展示一个完美的输入和对应的理想输出。
反例： 展示一个常见的错误输出，并标注"不要这样做"，帮助模型规避陷阱。
（5）把易变信息外置
Skill的定义文件应保持静态，避免硬编码易变数据。
使用占位符： 将API Key、版本号、文件路径等作为参数传入。
动态读取： 对于经常变化的业务规则，让Skill去读取外部配置文件或文档，而不是写在Prompt里。
（6）确定性动作脚本化
对于必须精确执行的动作，不要依赖LLM的自然语言生成。
工具优先： 如果需要重命名文件，直接调用
mv命令或文件系统工具，而不是让LLM生成一段"请重命名文件"的文字。代码执行： 复杂的计算或数据处理，应生成Python/Shell脚本并执行，确保结果100%准确。
（7）添加禁令和异常处理
负面约束： 明确列出禁止事项，如"严禁修改用户原有的注释"、"严禁删除任何依赖包"。
失败回退： 定义当工具调用失败或搜索无结果时，模型应该如何回应（例如："如果找不到文档，请告知用户并建议人工介入"）
二、真实场景测试
（1）触发测试
尝试用不同的说法（口语、专业术语、缩写）来触发Skill，确保路由机制能准确识别。输入包含相似关键词但意图完全不同的指令，确保Skill不会被误触发。
（2）功能测试
输入极长、极短或空的内容，观察Skill的稳定性。在长上下文环境中调用Skill，检查是否会被之前的对话历史干扰。对照SOP步骤，逐一检查模型的执行路径是否符合预期，输出格式是否严格达标。
| 测试类型 | 测试方法 | 测试目的 |
|---|---|---|
| 触发测试 | 语义泛化测试：尝试用不同的说法（口语、专业术语、缩写）来触发 Skill | 确保路由机制能准确识别用户意图 |
| 触发测试 | 抗干扰测试：输入包含相似关键词但意图完全不同的指令 | 确保 Skill 不会被误触发 |
| 功能测试 | 边界值测试：输入极长、极短或空的内容 | 观察 Skill 的稳定性 |
| 功能测试 | 多轮对话测试：在长上下文环境中调用 Skill | 检查是否会被之前的对话历史干扰 |
| 功能测试 | 人工验收：对照 SOP 步骤逐一检查 | 确保模型的执行路径符合预期，输出格式严格达标 |
三、参考
Claude官方Agent Skills编写规范
https://agentskills.io/specification