Skills skill-optimizer

审查并优化现有 skill 的触发语义、工作流、确认门槛和资源组织。当用户提到“优化 skill”“检查 skill 质量”“改进某个 skill”“重构技能说明”，或明确说明要优化哪些方面时使用。默认先审查并给计划，只有在用户明确确认开始修改后才实施。

install

source · Clone the upstream repo

git clone https://github.com/chujianyun/skills

Claude Code · Install into ~/.claude/skills/

T=$(mktemp -d) && git clone --depth=1 https://github.com/chujianyun/skills "$T" && mkdir -p ~/.claude/skills && cp -r "$T/skills/skill-optimizer" ~/.claude/skills/chujianyun-skills-skill-optimizer && rm -rf "$T"

manifest: skills/skill-optimizer/SKILL.md

source content

Skill Optimizer

先审查，再规划，最后在确认后修改。

设计模式

本 skill 主要采用：

Reviewer：先判断目标 skill 的问题，再给诊断
Inversion：先出计划并等待确认，不直接改文件
Generator（轻度）：在用户确认后，输出更清晰的 skill 结构或工作流

Gotchas

不要把“审查结论”和“直接开始改文件”混成一步
不要为了显得全面就偷偷扩大改动面
不要在没确认前修改目标 skill
不要为了“审查完整”而把无关 reference 全部读进上下文
如果用户明确只要某个方向优化，先围绕这个方向，不要擅自重构整个 skill

工作流

复制此清单并跟踪进度：

优化进度：
- [ ] 步骤 1：Scope（确定范围）
- [ ] 步骤 2：Review（审查目标 skill）
- [ ] 步骤 3：Plan（输出优化计划并等待确认）
- [ ] 步骤 4：Implement（确认后实施）
- [ ] 步骤 5：Verify（校验结果）

Step 1: Scope（确定范围）

先确认目标 skill 和本次优化范围。

优先采用用户明确提出的优化方向，例如触发词、description、结构拆分、脚本化、确认流程。
如果用户只说“优化这个 skill”，先做完整审查，再给出分优先级计划。
如果目标 skill 不明确，只问一个最短问题，不要一次追问很多细节。

Step 2: Review（审查目标 skill）

先读目标 skill 的

SKILL.md

，再按需读取它直接链接的

references/

、

scripts/

、

assets/

。

默认使用 references/review-checklist.md 做审查基线。
默认再结合 references/skill-design-review-framework.md 判断模式是否匹配、设计是否合理。
需要判断最佳实践取舍时，再读取 references/skill-creation-best-practices-claude-api-docs.md。
不要为了“审查完整”而把无关 reference 全部读入上下文。

重点检查：

触发语义是否清楚：
```
name
```
、目录名、
```
description
```
是否一致，且便于触发
工作流是否可靠：步骤是否清晰，是否存在必须确认却没卡住的环节
输出契约是否明确：审查结论、优化计划、最终修改结果是否分开
结构是否合适：正文是否过胖，是否应拆到
```
references/
```
/
```
scripts/
```
/
```
assets/
```
设计是否合理：模式是否匹配，是否存在过度设计、脚本缺失或资源组织问题
进度跟踪是否必要：多步骤工作流是否适合用 markdown checkbox 清单跟踪进度，若目标 skill 缺少且有必要，则提议增加

如果用户只要求微调某一部分（例如只改 description、只补 references、只修确认门槛），优先做局部审查，不要擅自把任务升级成整 skill 重构。

Step 3: Plan（输出优化计划并等待确认）

先给诊断，再给计划，不要直接改文件。

输出必须包含两个部分：

# Skill 审查结论

## 审查对象
- 目标 skill：...
- 本次范围：...

## 模式判断
- 主模式：...
- 次模式：...
- 当前判断：模式匹配 / 模式错位 / 模式不清

## 高优先级
- [问题] 影响触发、正确性或执行稳定性

## 中优先级
- [问题] 影响可维护性、可复用性或上下文成本

## 低优先级
- [问题] 体验提升项，可选

## 不改动项
- ...

## 额外建议
- ...

# 优化计划
1. 修改 [目标文件路径]
   - 变更内容：
   - 原因：
   - 是否受用户指定方向驱动：是/否

仅当用户明确回复“按计划执行”“开始修改”“确认修改”等开始执行类确认语时，才能进入实施阶段。

规则：

如果用户明确给了优化方向，先围绕这些方向出计划，再补充少量高价值附加建议。
如果发现超出本次范围的大问题，单独列为“额外建议”，不要偷偷扩大改动面。
未获得确认前，不要修改目标 skill。
“我看看”“有道理”“先这样”不算确认；只有明确开始执行类确认语才算进入 Step 4。

Step 4: Implement（确认后实施）

在用户确认后，再修改目标 skill。

优先改动计划中已确认的文件。
尽量小步重构；仅在确有收益时拆分新的
```
references/
```
、
```
scripts/
```
、
```
assets/
```
。
如果新增引用文件，确保它们都直接从目标
```
SKILL.md
```
链接，避免深层跳转。
保留用户原有有效内容；只删除重复、失效或与新流程冲突的部分。
如果用户确认语义含糊，继续停留在 Step 3，不要自行解释成“已确认”。

Step 5: Verify（校验结果）

改完后至少完成这些校验：

frontmatter 只包含
```
name
```
和
```
description
```
```
name
```
、目录名、触发语义一致
```
description
```
能独立表达触发条件
```
SKILL.md
```
主体比改动前更短、更清晰，且工作流可执行
新增
```
references/
```
是否只承载细节，没有和
```
SKILL.md
```
重复大段内容
如有“先审查后确认再修改”的门槛，是否在说明里写清楚
Step 3 模板是否明确写出范围、不改动项和可接受确认语

最后向用户汇报：

已修改的文件
已落实的优化方向
仍保留的风险或后续建议

审查标准

需要快速判定时，直接按这组优先级处理：

先修触发失败、确认缺失、流程不可执行的问题
再修结构臃肿、重复内容、资源组织混乱的问题
最后处理措辞润色、示例补充、可读性增强