Agent优化
- 作者仓库星标 606
- 作者更新于 实时读取
- 作者仓库 skills
- 领域
- 通用
- 兼容 Agent
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- 信任分
- 88 / 100 · 社区维护
- 作者 / 版本 / 许可
- @chujianyun · 未声明 license
- Token 消耗评级
- 低消耗
- 接入复杂程度
- 需简单配置
- 是否需要外部 API Key
- 需要 · Vendor-specific
- 兼容的系统
- 未声明(默认跨平台)
- 底层运行要求
- 无特殊要求
- 文件与系统权限
-
- 只读
- 允许写入 / 修改
- 网络行为
- 允许外网请求
- 安装命令数
- 26 条
档案由构建时根据 SKILL.md 与安装命令自动衍生,可能与作者实际意图存在差异。
需要注意: 未限定 allowed-tools,默认拥有全部工具权限。
---
name: skill-optimizer
description: 审查并优化现有 skill 的触发语义、工作流、确认门槛、资源组织、安全边界与文档分层。当用户提到“优化 skill”“检查 skill 质量”“改进某个 skill”“重构技能说明”,或明确…
category: 通用
runtime: 无特殊运行时
---
# skill-optimizer 输出预览
## PART A: 任务判断
- 适用问题:通用任务拆解、检查和交付。
- 输入要求:目标材料、限制条件、期望输出和验收方式。
- 证据边界:围绕“设计模式 / Gotchas / 工作流”读取原文规则,不把推断写成作者承诺。
## PART B: 执行结果
- **01** 任务判断:确认你的需求是否属于通用任务拆解、检查和交付,并标出输入、限制和预期结果。
- **02** 执行计划:优先按“设计模式 / Gotchas / 工作流”拆成步骤,说明每一步会读取什么、修改什么、产出什么。
- **03** 交付结果:给出可复制的命令、文件改动、检查清单或内容草稿,并说明如何继续迭代。
- **04** 风险边界:结合 读取文件、写入/修改文件、会按任务需要访问外部网络、需要准备 Vendor-specific API Key 给出执行前确认项。
## Running Rules
- 读取文件、写入/修改文件;会按任务需要访问外部网络;需要准备 Vendor-specific API Key。
- 先小样例验证,再放大到真实任务。
- 交付时同时给结果、检查口径和下一步迭代建议。 先确认触发方式
原文没有稳定的斜杠命令要求。安装验证后通常全局生效,直接在对话里点名这个 Skill 并描述任务即可。
给清楚输入和边界
告诉 Agent 目标文件或材料、期望结果、不可改范围、是否允许联网或执行命令。本 Skill 的权限画像是:读取文件、写入/修改文件。
小样例验证后再放大
先用一个小任务确认它会围绕“设计模式 / Gotchas / 工作流”工作;涉及文件或命令时,先看 diff、日志、预览或测试结果。
复核后再交付
检查最终产物是否包含明确结果、必要证据和下一步动作;如果输出泛泛而谈,就补充输入、边界和验收标准后重跑。
---
name: skill-optimizer
description: 审查并优化现有 skill 的触发语义、工作流、确认门槛、资源组织、安全边界与文档分层。当用户提到“优化 skill”“检查 skill 质量”“改进某个 skill”“重构技能说明”,或明确…
category: 通用
source: chujianyun/skills
---
# skill-optimizer
## 什么时候使用
- 把通用方向的常用动作沉淀成 Agent 可调用的技能 适合处理通用任务拆解、检查、交付和复盘,核心价值是把输入、判断、执行、验证和交付边界固定下来,避免 Agent 泛泛回答。 把任务拆成可执行、可检查、可继续迭代的步骤;使用前要准备…
- 面向通用任务拆解、检查和交付,优先处理能明确输入、步骤和验收标准的工作。
## 需要提供什么
- 目标材料、目录范围、期望结果和不可改动内容。
- 是否允许联网、执行命令、读写文件或调用外部服务。
## 执行规则
- 围绕「设计模式 / Gotchas / 工作流」组织步骤,不把推断写成作者事实。
- 读取文件、写入/修改文件;会按任务需要访问外部网络;需要准备 Vendor-specific API Key。
- 先跑小样例,确认结果可检查后再扩大任务范围。
## 输出要求
- 给出最终产物、关键证据、验证方式和下一步动作。
- 信息不足时标记 unknown,不编造命令、平台或依赖。 证据边界与执行链路
作者原文负责流程事实;仓库文件负责来源和命令;流狐只补充适用场景、限制和质量判断。
skill "skill-optimizer" {
输入层 -> 用户目标 + 目标文件 + 禁止范围 + 验收标准
上下文层 -> 设计模式 / Gotchas / 工作流
规则层 -> SKILL.md 触发条件 / 执行顺序 / 输出格式
运行层 -> 无特殊运行时 | 读取文件、写入/修改文件 | 会按任务需要访问外部网络
安全层 -> 需要准备 Vendor-specific API Key + 小任务验证 + diff / 日志复核
输出层 -> 可复制结果 + 检查清单 + 下一步迭代
} 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/索引补充、措辞润色、示例补充、可读性增强
先判断是否适合
作者设计意图
作者的方法与取舍
边界和复核