# Optimize

> 审查并优化已有 skill 的触发语义、工作流、确认门槛、资源组织、安全边界与文档分层。 当用户提到「优化 skill」「检查 skill 质量」「改进某个 skill」「重构技能说明」， 或明确说明要优化哪些方面时使用。默认先审查并给计划，只有在用户明确确认开始 修改后才实施。

- Skill: `tubeliu/optimize` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add tubeliu/optimize`
- Raw SKILL.md: https://api.skillmd.com/api/skills/tubeliu/optimize/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: tubeliu (https://skillmd.com/u/tubeliu)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/tubeliu/optimize

---


> **跨平台兼容性 checklist**（Windows / macOS / Linux）：
> 1. **本 skill 不带脚本**——纯 markdown，仅指引 AI 读 SKILL.md / references / 目标 skill 文件，无平台敏感命令。
> 2. **目标 skill 路径**：用绝对路径或 cwd 相对路径，避免硬编码反斜杠 `\`，统一用正斜杠 `/`。
> 3. **可执行检测**（若审查结论里要给目标 skill 补安装命令）：建议 `which` / `where` / `Get-Command`，不用 `command -v`。

<SUBAGENT-STOP>
此技能给协调者读。**判定你是否子智能体**：如果你的当前角色定义来自 Task prompt 而非 SKILL.md 自然加载（即调用方在 Task 工具的 prompt 字段里塞了 agents/<role>.md 的内容），你就是子智能体；跳过本 SKILL.md 的工作流编排部分，只执行 Task prompt 给你的具体任务。本 skill 自身不通过 Task 派子智能体，正常使用时不会触发此分支。
</SUBAGENT-STOP>

# Skill Optimizer

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

## 设计模式

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

## Gotchas

- 不要把"审查结论"和"直接开始改文件"混成一步
- 不要为了显得全面就偷偷扩大改动面
- 不要在没确认前修改目标 skill
- 不要为了"审查完整"而把无关 reference 全部读进上下文
- 如果用户明确只要某个方向优化，先围绕这个方向，不要擅自重构整个 skill
- 如果发现疑似敏感信息，不要在回复里回显完整内容，只描述类型、位置和风险
- 如果发现高副作用操作，不要默认放行；要补确认门槛或显式提醒用户

## 工作流

复制此清单并跟踪进度：

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

### Step 1: Scope（确定范围）

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

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

### Step 2: Review（审查目标 skill）

先读目标 skill 的 `SKILL.md`，再按需读取它直接链接的 `references/`、`scripts/`、`assets/`、`README.md`。

- 默认使用 [references/review-checklist.md](references/review-checklist.md) 做审查基线。
- 默认再结合 [references/skill-design-review-framework.md](references/skill-design-review-framework.md) 判断模式是否匹配、设计是否合理。
- 需要判断最佳实践取舍时，再读取 [references/skill-creation-best-practices-claude-api-docs.md](references/skill-creation-best-practices-claude-api-docs.md)。
- 不要为了"审查完整"而把无关 reference 全部读入上下文。
- 如果目标 skill 的上层目录名是 `skills`，可额外查看同级目录名与必要的 `description`，判断是否存在应合并、复用或避免抢触发的相邻 skill；不要把所有同级 skill 全量读进上下文。

重点检查：

- 触发语义是否清楚：`name`、目录名、`description` 是否一致，且便于触发
- 工作流是否可靠：步骤是否清晰，是否存在必须确认却没卡住的环节
- 异常处理是否充分：缺文件、缺输入、命令失败、网络失败、鉴权失败、空结果等场景是否有降级或停机策略
- 输出契约是否明确：审查结论、优化计划、最终修改结果是否分开
- 结构是否合适：正文是否过胖，是否应拆到 `references/` / `scripts/` / `assets/`
- 渐进式加载是否顺手：文件较多时，是否提供根目录或子目录索引，帮助按需加载
- 设计是否合理：模式是否匹配，是否存在过度设计、脚本缺失或资源组织问题
- 外部依赖是否可安装：若依赖外部 skill、CLI、服务或运行时，是否写清安装、校验和自动安装命令
- 是否包含敏感信息：例如 API Key、Token、Cookie、账号、私有地址或其他不应随 skill 分发的内容
- 是否包含敏感操作：删除、覆盖、部署、发送消息、批量写入、付费调用、联网改状态等高副作用操作，是否需要确认或额外提醒
- Skill 粒度是否合理：是否过粗导致职责混杂，或过细导致触发分散、维护成本过高
- README / SKILL 分工是否清楚：`README.md` 面向人，`SKILL.md` 面向 AI，内容是否重复或错位
- 进度跟踪是否必要：多步骤工作流是否适合用 markdown checkbox 清单跟踪进度，若目标 skill 缺少且有必要，则提议增加

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

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

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

输出必须包含两个部分：

```markdown
# Skill 审查结论

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

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

## 安全与依赖
- 敏感信息：未发现 / 存疑 / 已发现（仅描述类型与位置，不回显具体值）
- 敏感操作：低 / 中 / 高风险；是否需要确认门槛：是 / 否
- 外部依赖：无 / 有；安装说明是否完整：完整 / 不完整

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

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

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

## 不改动项
- ...

## 额外建议
- ...

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

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

规则：

- 如果用户明确给了优化方向，先围绕这些方向出计划，再补充少量高价值附加建议。
- 如果发现超出本次范围的大问题，单独列为"额外建议"，不要偷偷扩大改动面。
- 未获得确认前，不要修改目标 skill。
- "我看看""有道理""先这样"不算确认；只有明确开始执行类确认语才算进入 Step 4。
- 如果发现疑似敏感信息或高风险副作用，计划里要单列风险与处理方案；必要时要求用户额外确认。

### Step 4: Implement（确认后实施）

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

- 优先改动计划中已确认的文件。
- 尽量小步重构；仅在确有收益时拆分新的 `references/`、`scripts/`、`assets/`。
- 如果新增引用文件，确保它们都直接从目标 `SKILL.md` 链接，避免深层跳转。
- 如果目标 skill 缺少 `README.md`，补一份面向人的 README，重点说明使用场景、主要功能、风险和边界；不要把执行细则原样复制自 `SKILL.md`。
- 如果目标 skill 文件较多且不便按需加载，补充根目录或子目录索引文件，说明何时读取哪个文件。
- 如果 skill 依赖外部 skill、CLI、服务或运行时，补上可直接执行的安装 / 校验指令，便于 AI 自动安装。
- 如果发现疑似敏感信息，先提醒并确认，再决定删除、迁移到配置或改成占位说明。
- 如果存在高副作用操作，补确认门槛、风险提示和禁止默认执行的规则。
- 保留用户原有有效内容；只删除重复、失效或与新流程冲突的部分。
- 如果用户确认语义含糊，继续停留在 Step 3，不要自行解释成"已确认"。

### Step 5: Verify（校验结果）

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

- frontmatter 只包含 `name` 和 `description`（本仓 skill 可同时含 `allowed-tools`，因 Claude Code plugin 约定）
- `name`、目录名、触发语义一致
- `description` 能独立表达触发条件
- `SKILL.md` 主体比改动前更短、更清晰，且工作流可执行
- 新增 `references/` 是否只承载细节，没有和 `SKILL.md` 重复大段内容
- 文件较多时是否存在索引，且索引能帮助渐进式加载
- 异常场景是否有处理策略或显式停止条件
- 外部依赖是否附带安装 / 校验命令，便于自动安装
- 是否移除了明文敏感信息，或至少显式提醒不要直接分发
- 敏感操作是否有确认门槛、风险提示和默认禁止条件
- Skill 粒度是否合适；若位于 `skills/` 下，是否已评估同级 skill 的合并空间
- `README.md` 是否存在，且明确与 `SKILL.md` 的分工不同
- 如有"先审查后确认再修改"的门槛，是否在说明里写清楚
- Step 3 模板是否明确写出范围、不改动项和可接受确认语

最后向用户汇报：

- 已修改的文件
- 已落实的优化方向
- 是否新增 README / 索引 / 安装说明 / 风险确认门槛
- 仍保留的风险或后续建议

## 审查标准

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

1. 先修敏感信息泄露、敏感操作失控、触发失败、确认缺失、流程不可执行的问题
2. 再修异常处理缺失、依赖不可安装、结构臃肿、重复内容、资源组织混乱的问题
3. 最后处理粒度微调、README/索引补充、措辞润色、示例补充、可读性增强