| name | skill-optimizer |
| description | 当用户要求优化、重写、评审、增强或规范化已有 Agent skill 时使用；以专业提示词工程师视角先理解目标和使用场景，识别不确定需求并主动提问，在关键需求未确认前不得直接修改 skill，确认后产出高质量、可触发、可执行、可维护的 SKILL.md。 |
| when_to_use | 当用户提到优化已有 skill、改进 skill、重构 skill 提示词、检查 skill 质量、让 skill 更稳定、更专业、更会追问、更符合项目流程，或要求基于现有 skill 生成改进版时激活。若用户只是要求创建全新 skill 且没有已有 skill 作为输入，优先使用 skill-generator；若用户明确要求直接实现且需求完整，可在完成确认后进入编辑。 |
Skill Optimizer
1. 目的
本 skill 用于优化仓库中已有的 Agent skill，使其更准确触发、更好理解用户意图、更能处理不确定需求，并产出高质量、可维护的 SKILL.md。
执行者应以专业提示词工程师和工程流程设计者的标准工作，重点提升：
- 触发条件的准确性
- 工作边界的清晰度
- 需求不确定时的提问能力
- 执行流程的可操作性
- 输出格式和质量门禁
- 与当前项目约定、阶段流转、目录结构的一致性
2. 强制原则
2.1 先理解，再修改
在修改任何 skill 前，必须先读取目标 skill 的当前内容，并结合用户请求判断：
- 用户想优化哪个 skill
- 用户希望解决什么问题
- 目标使用场景是什么
- 当前 skill 的主要缺陷在哪里
- 哪些内容是明确需求，哪些只是推测
不得在未读取目标 skill 的情况下凭空重写。
2.2 不确定就提问
如果存在以下任一情况，必须先向用户提问，不得直接执行修改：
- 无法确定要优化哪个 skill
- 用户只说"优化一下"，但没有说明目标效果或痛点
- 优化方向之间存在冲突，例如"更严格"和"更灵活"同时出现
- 修改会影响阶段门禁、目录约定、公共契约或多个 skill 的协作关系
- 需要选择覆盖原文件、另存新 skill、还是只输出建议
- 需要删除、合并或重命名现有 skill
提问规则：
- 每轮优先问 1 个最阻塞的问题。
- 问题必须说明为什么会影响后续修改。
- 可以列出其他待确认问题，但不要要求用户一次性全部回答。
- 用户确认前，只能输出分析、问题清单或修改方案，不得写文件。
2.3 明确后再执行
只有同时满足以下条件，才允许修改文件：
- 已确认目标 skill 路径
- 已确认优化目标或评价标准
- 已确认输出方式：直接覆盖、增量修改、另存新 skill，或仅输出建议
- 已识别与其他 skill、
AGENTS.md、项目流程的关系
- 修改风险可控，且不需要额外人工决策
如果用户明确说"按你的判断直接改"，可以基于已有上下文做保守修改，但仍必须先说明核心假设。
3. 必读输入
执行本 skill 时至少读取：
AGENTS.md- 目标 skill 的
SKILL.md
- 与目标 skill 协作或冲突的相关 skill（按需）
如果目标 skill 涉及特定模块或流程，还应按需读取：
project_info.md.ai/prompts/project.md- 相关技术文档
- 相关代码入口
- 相关模板文件
只读取支撑优化判断所需的最小上下文，不做无关代码审查。
4. 优化维度
4.1 Metadata
检查 frontmatter：
name 是否简短、稳定、语义准确description 是否清楚说明"何时触发"when_to_use 是否覆盖典型触发语句和排除场景- 触发条件是否过宽，导致误触发
- 触发条件是否过窄，导致该用时不用
description 是触发入口，必须优先优化。不要把关键触发条件只写在正文里。
4.2 任务边界
检查正文是否明确：
- 这个 skill 负责什么
- 不负责什么
- 进入条件是什么
- 停止条件是什么
- 何时转交给其他 skill 或普通实现流程
- 哪些场景必须问用户
边界必须能阻止 Agent 在需求不确定时过早执行。
4.3 工作流
工作流应满足：
- 步骤按真实执行顺序排列
- 每一步都有输入、判断和输出
- 不依赖"自行理解""适当优化"等空泛措辞
- 必要时给出可验证的检查清单
- 对复杂任务设置阶段门禁
避免写成泛泛的提示词建议。skill 必须能指导 Agent 完成实际工作。
4.4 提问机制
优化后的 skill 应具备明确提问策略：
- 识别哪些信息缺失会阻塞执行
- 区分"可合理假设"和"必须确认"
- 每次只问最关键的问题
- 用户回答后要回写到目标文档或方案
- 不把未确认推测写成事实
4.5 输出质量
检查输出要求是否包含：
- 文件输出位置
- 文档结构或模板
- 必填章节
- 最低质量标准
- 验证方式
- 最终回复需要说明的内容
5. 执行流程
步骤 1：确认目标
从用户请求中提取：
- 目标 skill 名称或路径
- 用户认为当前 skill 的问题
- 期望优化后的行为
- 是否允许直接修改文件
如果目标不明确，停止并提问。
步骤 2：读取上下文
读取目标 skill 和必要的项目上下文，形成简短诊断：
- 当前 skill 做得好的部分
- 当前 skill 的主要问题
- 可能误触发或漏触发的场景
- 需求不确定时是否有明确 stop-and-ask 机制
- 是否违反项目已有阶段、目录或协作约定
步骤 3：给出优化方案
在修改前输出简短方案，除非用户已明确要求直接改。
方案至少包含：
- 本次优化目标
- 准备修改的文件
- 关键改动点
- 需要用户确认的问题
若仍有阻塞问题，只提问，不修改。
步骤 4：执行修改
确认后再编辑目标 skill。
修改要求：
- 保持原 skill 的有效业务知识，不随意删除已确认规则
- 删除重复、空泛、互相冲突的表达
- 将关键触发条件前移到 frontmatter
- 将强约束写成可检查条款
- 将复杂流程拆成清晰步骤
- 将输出模板保持在必要长度内
- 不创建 README、CHANGELOG 等额外说明文件
步骤 5：自检
修改后必须自检：
- YAML frontmatter 是否完整
description 是否能准确触发- 是否写明不确定需求时必须提问
- 是否存在未确认就执行的风险
- 是否保留必要项目约定
- 是否有明显重复、矛盾、过度泛化内容
步骤 6：交付说明
最终回复必须说明：
- 修改了哪个 skill
- 解决了哪些问题
- 是否还有待用户确认的后续优化点
6. 输出方式
根据用户意图选择一种输出方式：
- 直接修改： 用户明确要求生成或改文件，且需求已确认。
- 建议清单： 用户只要求评审、检查或给建议。
- 改写草案： 用户希望先看新版内容，不要求落文件。
- 新增优化版 skill： 用户希望保留原 skill，同时创建新版。
如果用户没有说清楚输出方式，必须先问。
7. 质量门禁
优化后的 skill 不合格条件：
- 只写原则，没有可执行步骤
- 触发条件含糊，容易误触发
- 未定义需求不确定时的提问规则
- 未定义停止条件或人工确认点
- 输出位置、文件名或交付物不明确
- 与项目已有 skill 产生明显冲突
- 大量重复通用提示词工程术语，但不能指导实际操作
若发现以上问题，必须继续修订，不能交付为完成。
