skill-optimizer
- Repo stars 606
- Author updated Live
- Author repo skills
- Domain
- Other
- Compatible agents
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- Trust score
- 88 / 100 · community maintained
- Author / version / license
- @chujianyun · no license declared
- Token usage
- Lean
- Setup complexity
- Guided setup
- External API key
- Required · Vendor-specific
- Operating systems
- Unspecified (assume cross-platform)
- Runtime requirements
- No special requirements
- Permissions
-
- Read-only
- Write / modify
- Network behavior
- External requests
- Install commands
- 26 variants
Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.
Heads up: 未限定 allowed-tools,默认拥有全部工具权限。
---
name: skill-optimizer
description: 先审查,再规划,最后在确认后修改。 先确认目标 skill 和本次优化范围。 先读目标 skill 的 SKILL.md,再按需读取它直接链接的 references/、scripts/、as…
category: other
runtime: no special runtime
---
# skill-optimizer output preview
## PART A: Task fit
- Use case: 先审查,再规划,最后在确认后修改。 先确认目标 skill 和本次优化范围。 先读目标 skill 的 SKILL.md,再按需读取它直接链接的 references/、scripts/、assets/、README.md。 如果用户只要求微调某一部分(例如只改 description、只补 references、只修确认门槛),优先做局部审查,不要擅自把任务升级成整 skill 重构。 requires Vendor-specific API key. Works with Claude Code, Cursor, Cline and 23 more..
- Inputs: target material, constraints, expected output, and acceptance criteria.
- Evidence boundary: follow “设计模式 / Gotchas / 工作流” and do not present inference as author intent.
## PART B: Execution result
- **01** The card summarizes the use case; runtime output centers on “先审查,再规划,最后在确认后修改。 先确认目标 skill 和本次优化范围。 先读目标 skill 的 SKILL.md,再按需读取它直接链接的 references/、scripts/、assets/、README.md。 如果用户只要求微调某一部分(例如只改 description、只补 references、只修确认门槛),优先做局部审查,不要擅自把任务升级成整 skill 重构。 requires Vendor-specific API key. Works with Claude Code, Cursor, Cline and 23 more.”.
- **02** When the source has headings, the agent prioritizes “设计模式 / Gotchas / 工作流” so the result follows the author’s structure.
- **03** Typical output includes task judgment, concrete steps, required commands or file edits, validation, and follow-up options.
- **04** Risk context follows the fingerprint: read files, write/modify files; may access external network resources; requires Vendor-specific API keys.
## Running Rules
- read files, write/modify files; may access external network resources; requires Vendor-specific API keys.
- Validate with a small sample before expanding scope.
- Return the result, validation criteria, and next iteration options. The source does not require a stable slash command. After installation, invoke the skill by name and describe the task.
Name target files or source material, expected output, forbidden changes, and whether network or shell access is allowed. Permission fingerprint: read files, write/modify files.
Start with a small task and check whether the result follows “设计模式 / Gotchas / 工作流”. Inspect diffs, logs, previews, or tests before expanding scope.
Confirm the final output includes a concrete result, evidence, and next action. If it stays generic, tighten inputs, boundaries, and acceptance criteria.
---
name: skill-optimizer
description: 先审查,再规划,最后在确认后修改。 先确认目标 skill 和本次优化范围。 先读目标 skill 的 SKILL.md,再按需读取它直接链接的 references/、scripts/、as…
category: other
source: chujianyun/skills
---
# skill-optimizer
## When to use
- 先审查,再规划,最后在确认后修改。 先确认目标 skill 和本次优化范围。 先读目标 skill 的 SKILL.md,再按需读取它直接链接的 references/、scripts/、assets/、README.md。 如果用户只…
- Use it when the task has clear inputs, repeatable steps, and validation criteria.
## What to provide
- Target material, scope, expected result, and forbidden changes.
- Whether network, commands, file writes, or external services are allowed.
## Execution rules
- Organize steps around “设计模式 / Gotchas / 工作流” and keep inference separate from source facts.
- read files, write/modify files; may access external network resources; requires Vendor-specific API keys.
- Validate with a small sample before expanding the task.
## Output requirements
- Return the deliverable, key evidence, validation method, and next action.
- Mark missing information as unknown; do not invent commands, platforms, or dependencies. The author source anchors workflow facts; repository files anchor sources and commands; Fluxly only adds fit, limitations, and quality judgment.
skill "skill-optimizer" {
input -> user goal + target files + boundaries + acceptance criteria
context -> 设计模式 / Gotchas / 工作流
rules -> SKILL.md triggers / order / output contract
runtime -> no special runtime | read files, write/modify files | may access external network resources
guardrails -> requires Vendor-specific API keys + small-sample validation + diff/log review
output -> copyable result + checklist + next iteration
} 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、结构拆分、脚本化、确认流程、安全边界、README/索引设计。
- 如果用户只说“优化这个 skill”,先做完整审查,再给出分优先级计划。
- 如果目标 skill 不明确,只问一个最短问题,不要一次追问很多细节。
Step 2: Review(审查目标 skill)
先读目标 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;不要把所有同级 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(输出优化计划并等待确认)
先给诊断,再给计划,不要直接改文件。
输出必须包含两个部分:
# 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 name、目录名、触发语义一致description能独立表达触发条件SKILL.md主体比改动前更短、更清晰,且工作流可执行- 新增
references/是否只承载细节,没有和SKILL.md重复大段内容 - 文件较多时是否存在索引,且索引能帮助渐进式加载
- 异常场景是否有处理策略或显式停止条件
- 外部依赖是否附带安装 / 校验命令,便于自动安装
- 是否移除了明文敏感信息,或至少显式提醒不要直接分发
- 敏感操作是否有确认门槛、风险提示和默认禁止条件
- Skill 粒度是否合适;若位于
skills/下,是否已评估同级 skill 的合并空间 README.md是否存在,且明确与SKILL.md的分工不同- 如有“先审查后确认再修改”的门槛,是否在说明里写清楚
- Step 3 模板是否明确写出范围、不改动项和可接受确认语
最后向用户汇报:
- 已修改的文件
- 已落实的优化方向
- 是否新增 README / 索引 / 安装说明 / 风险确认门槛
- 仍保留的风险或后续建议
审查标准
需要快速判定时,直接按这组优先级处理:
- 先修敏感信息泄露、敏感操作失控、触发失败、确认缺失、流程不可执行的问题
- 再修异常处理缺失、依赖不可安装、结构臃肿、重复内容、资源组织混乱的问题
- 最后处理粒度微调、README/索引补充、措辞润色、示例补充、可读性增强
Decide Fit First
Design Intent
How To Use It
Boundaries And Review