用途
Skill Optimizer 用于审查并优化现有 skill。它关注的方面包括：触发语义、工作流、确认门槛、资源组织、安全边界与文档分层。当用户提到“优化 skill”“检查 skill 质量”“改进某个 skill”“重构技能说明”，或明确说明要优化哪些方面时使用。
其核心原则是：先审查，再规划，最后在确认后修改。默认先审查并给出计划，只有在用户明确确认开始修改后才实施。
主要能力
该 skill 采用三种设计模式：
- Reviewer：先判断目标 skill 的问题，再给诊断。
- Inversion：先出计划并等待确认，不直接改文件。
- Generator（轻度）：在用户确认后，输出更清晰的 skill 结构或工作流。
审查时重点检查以下方面：
- 触发语义是否清楚：name、目录名、description 是否一致，且便于触发。
- 工作流是否可靠：步骤是否清晰，是否存在必须确认却没卡住的环节。
- 异常处理是否充分：缺文件、缺输入、命令失败、网络失败、鉴权失败、空结果等场景是否有降级或停机策略。
- 输出契约是否明确：审查结论、优化计划、最终修改结果是否分开。
- 结构是否合适：正文是否过胖，是否应拆到 references/、scripts/、assets/。
- 渐进式加载是否顺手：文件较多时，是否提供根目录或子目录索引，帮助按需加载。
- 设计是否合理：模式是否匹配，是否存在过度设计、脚本缺失或资源组织问题。
- 外部依赖是否可安装：若依赖外部 skill、CLI、服务或运行时，是否写清安装、校验和自动安装命令。
- 是否包含敏感信息：例如 API Key、Token、Cookie、账号、私有地址或其他不应随 skill 分发的内容。
- 是否包含敏感操作：删除、覆盖、部署、发送消息、批量写入、付费调用、联网改状态等高副作用操作，是否需要确认或额外提醒。
- Skill 粒度是否合理：是否过粗导致职责混杂，或过细导致触发分散、维护成本过高。
- README / SKILL 分工是否清楚：README.md 面向人，SKILL.md 面向 AI，内容是否重复或错位。
- 进度跟踪是否必要：多步骤工作流是否适合用 markdown checkbox 清单跟踪进度，若目标 skill 缺少且有必要，则提议增加。
使用方式
工作流分为五个步骤，可用清单跟踪进度：
- 步骤 1：Scope（确定范围）
- 步骤 2：Review（审查目标 skill）
- 步骤 3：Plan（输出优化计划并等待确认）
- 步骤 4：Implement（确认后实施）
- 步骤 5：Verify（校验结果）
Step 1 确定范围：先确认目标 skill 和本次优化范围。优先采用用户明确提出的优化方向，例如触发词、description、结构拆分、脚本化、确认流程、安全边界、README/索引设计。如果用户只说“优化这个 skill”，先做完整审查，再给出分优先级计划。如果目标 skill 不明确，只问一个最短问题。
Step 2 审查：先读目标 skill 的 SKILL.md，再按需读取它直接链接的 references/、scripts/、assets/、README.md。默认使用 references/review-checklist.md 做审查基线，结合 references/skill-design-review-framework.md 判断模式是否匹配、设计是否合理。需要判断最佳实践取舍时，再读取 references/skill-creation-best-practices-claude-api-docs.md。不要为了“审查完整”而把无关 reference 全部读入上下文。如果目标 skill 的上层目录名是 skills，可额外查看同级目录名与必要的 description，判断是否存在应合并、复用或避免抢触发的相邻 skill。
Step 3 输出优化计划并等待确认：先给诊断，再给计划，不要直接改文件。输出包含“Skill 审查结论”和“优化计划”两部分。审查结论包括审查对象、模式判断、安全与依赖、高/中/低优先级问题、不改动项、额外建议。优化计划逐条列出修改目标文件路径、变更内容、原因、是否受用户指定方向驱动。仅当用户明确回复“按计划执行”“开始修改”“确认修改”等开始执行类确认语时，才能进入实施阶段。“我看看”“有道理”“先这样”不算确认。
Step 4 确认后实施：在用户确认后，再修改目标 skill。优先改动计划中已确认的文件，尽量小步重构。如果新增引用文件，确保它们都直接从目标 SKILL.md 链接。如果目标 skill 缺少 README.md，补一份面向人的 README。如果文件较多且不便按需加载，补充根目录或子目录索引文件。如果依赖外部 skill、CLI、服务或运行时，补上可直接执行的安装/校验指令。如果发现疑似敏感信息，先提醒并确认。如果存在高副作用操作，补确认门槛、风险提示和禁止默认执行的规则。保留用户原有有效内容。
Step 5 校验结果：改完后至少完成这些校验：frontmatter 只包含 name 和 description；name、目录名、触发语义一致；description 能独立表达触发条件；SKILL.md 主体比改动前更短、更清晰，且工作流可执行；新增 references/ 只承载细节，没有和 SKILL.md 重复大段内容；文件较多时是否存在索引；异常场景是否有处理策略或显式停止条件；外部依赖是否附带安装/校验命令；是否移除了明文敏感信息；敏感操作是否有确认门槛；Skill 粒度是否合适；README.md 是否存在且分工不同；确认门槛是否写清楚；Step 3 模板是否明确写出范围、不改动项和可接受确认语。最后向用户汇报已修改的文件、已落实的优化方向、是否新增 README/索引/安装说明/风险确认门槛、仍保留的风险或后续建议。
适用场景
适用于需要审查或优化已有 skill 的场景，包括检查 skill 质量、改进某个 skill、重构技能说明，或针对触发词、description、结构拆分、脚本化、确认流程、安全边界、README/索引设计等特定方向进行优化。
限制
- 默认先审查并给计划，只有在用户明确确认开始修改后才实施。
- 不要把“审查结论”和“直接开始改文件”混成一步。
- 不要为了显得全面就偷偷扩大改动面。
- 不要在没确认前修改目标 skill。
- 不要为了“审查完整”而把无关 reference 全部读进上下文。
- 如果用户明确只要某个方向优化，先围绕这个方向，不要擅自重构整个 skill。
- 如果发现疑似敏感信息，不要在回复里回显完整内容，只描述类型、位置和风险。
- 如果发现高副作用操作，不要默认放行；要补确认门槛或显式提醒用户。
- 如果用户确认语义含糊，继续停留在 Step 3，不要自行解释成“已确认”。
审查标准优先级：先修敏感信息泄露、敏感操作失控、触发失败、确认缺失、流程不可执行的问题；再修异常处理缺失、依赖不可安装、结构臃肿、重复内容、资源组织混乱的问题；最后处理粒度微调、README/索引补充、措辞润色、示例补充、可读性增强。