skill-optimizer

Skill Optimizer

路径选择

路径	行为	典型触发
A — 结构化改写	读目标 skill → 诊断与计划 → 用户确认后才改 SKILL.md / references / scripts	用户附着或指定路径、说「改 description」「拆 references」「加确认步骤」
B — 会话审计	扫描本机 skill 目录与历史会话 jsonl，只输出报告，绝不写 skill 文件	/optimize-skill、/skill-audit、「分析我所有 skills」「skill 从不触发」「只审计不要改」

判定： 用户明确「只分析 / 只出报告 / 不要改」→ B。用户点名要改某 skill 且未禁止写文件 → A（无确认仍不得改）。「先看全局再改」→ 先做 B，再在用户要求下对单项切 A。

共用规则

• 官方规范优先（双轨）：每次启动先执行下方 Step 0 — Fetch Spec（三级降级：代理 → 直连 → 本地缓存），未完成前禁止进入诊断、计划或改写阶段。
• 路径 B：只读。 不得修改任何 skill 文件，只交付报告（Step 0 对缓存文件的覆盖是允许的例外，因为它属于 skill 自身的资产更新而非被审计 skill 的修改）。
• 路径 A：确认门槛。 不得把「审查结论」与「直接改文件」混为一步；未确认不得改目标 skill。
• 路径 B：八维齐全。 不得跳过 references/session-audit-dimensions.md 中的 4.2、4.3、4.5b、4.8；缺数据写 N/A — insufficient session data。
• 量化与证据： 报告用次数、比例、日期范围；欠触发须引用真实用户原句；description 改写用建议语气并点明依据（静态表条目、官方规范条款或研究结论）。
• 范围克制： 用户只要某一方向（如只改 description）时，围绕该方向计划，不擅自整 skill 重写；不要为了「全面」把无关 reference 全读进上下文。
• 路径统一用 ${CLAUDE_SKILL_DIR}： 任何「读 / 写 / 引用本 skill 资源」的动作（含脚本、Bash、Read、Write、WebFetch 后落盘）都使用 ${CLAUDE_SKILL_DIR}/... 形式，不写死绝对路径，不写仓库相对路径。

Pipeline 类 skill 的特别处理

当目标 skill 在 Step 2 Review 中被判定为 Pipeline（主模式或次模式），或满足 ≥3 个 workflow-skill-creator 适用信号（≥3 顺序步骤 / 跨步骤状态传递 / 需脚本辅助 / 需进度文件 / 强制顺序、跳步导致失败），按以下规则叠加评审基准：

• 必读资产：${CLAUDE_SKILL_DIR}/../workflow-skill-creator/references/architecture_patterns.md（六大架构模式）与 quality_checklist.md（七维自检）
• 基准合并：Step 5 Verify 须在 review-checklist.md 之上叠加 workflow-skill-creator 的 quality_checklist；针对编排专门规范遇冲突时以 workflow-skill-creator 为准
• Plan 输出义务：Step 3 Plan 必须在末段写明「目标 skill 已识别为 Pipeline，对照 workflow-skill-creator 六大模式逐项核对」并列出未达标项
• 跨 skill 路径：两 skill 同属 agents-dev plugin，故用 ${CLAUDE_SKILL_DIR}/../workflow-skill-creator/... 引用；若日后被拆到不同 plugin，需改为目标 plugin 的解析路径

路径 B 工作流（概要）

1. Step 0 — Fetch Spec：执行下方「Step 0 详细流程」；本轮基准来自最新抓取或 ${CLAUDE_SKILL_DIR}/references/official-spec-fetch.md 缓存。
2. 锁定范围：/optimize-skill 全量，或 /optimize-skill a b 指定多个 name。
3. 发现 skill：按 session-audit-dimensions.md 中的目录顺序扫描并去重，读 frontmatter 与步骤结构。
4. 采集会话：Claude Code / Codex jsonl 字段差异见该文档；Codex 注意「加载 ≠ 已按 skill 执行」。
5. 跑满八维 + 综合分：表格、权重、报告骨架均见该文档；遇到与官方规范不一致处，须在报告中以「依据：官方规范 §X」标注。
6. 输出：使用该文档中的 Report Format；P0 / P1 / P2 分级；报告首段写明「本轮使用的官方规范来源（live / cache）+ fetched_at」。