Improve Skill Bespoke To CodeBase

核心用法

improve-skill 是一个元技能（meta-skill），用于审计和优化其他 Factory Droid 技能。它通过6步评估框架对目标技能进行深度体检：① 技能定义审计（检查指令清晰度、完整性、错误处理）；② 代码库适配分析（识别技能未覆盖的文件类型、目录结构、框架模式）；③ 边界情况发现（检测异常文件、编码问题、框架魔法目录等）；④ 输出质量评估（验证历史生成物的准确性、一致性、完整性）；⑤ 可组合性检查（评估与其他技能的协作能力、幂等性、状态管理）；⑥ 用户体验审查（评估调用 friction、反馈质量、可恢复性）。评估完成后输出结构化改进报告，包含评分卡、优先级排序的改进建议、边界情况清单及 SKILL.md 补丁建议，并支持直接实施改进。

显著优点

• 系统化评估框架：6大维度覆盖技能全生命周期，避免主观判断，诊断结果可复现
• 项目特异性洞察：结合当前代码库实际结构（文件类型、框架模式、规模）生成建议，而非通用模板
• 可执行输出：每个问题都附带具体修复方案、工作量估算和行级补丁建议，直接可用于迭代
• 闭环验证：支持改进后重跑样本验证，量化前后对比
• 自动触发机制：可监听用户反馈（"它漏了X"）或观察到的摩擦自动建议评估

潜在缺点与局限性

• 依赖历史调用数据：输出质量评估需要技能曾被调用过，新项目首次使用可能无法完整评估第4维度
• 模拟成本：无历史数据时需对5-10个代表性文件进行"干运行"模拟，增加 token 消耗
• 框架覆盖盲区：评估框架虽全面，但对新兴框架或高度定制化架构的检测可能滞后于实际演进
• 改进实施风险：直接编辑 SKILL.md 可能引入新错误，需要验证步骤但用户可能跳过
• 评估者能力上限：元技能的评估质量受限于当前模型的代码理解能力，复杂边界情况可能误判

适合人群

• 技能维护者：需要持续迭代官方或自定义技能以适应多项目场景的开发者
• DevOps/平台工程师：负责维护组织内技能库、确保技能与项目模板同步的团队
• 高级用户：对现有技能输出不满意、希望系统性优化而非打补丁的终端用户
• 技能迁移场景：将技能从 A 项目迁移到 B 项目时，快速识别适配差距

常规风险

• 误报边界情况：可能将项目特有的合法模式标记为"需处理"，导致技能过度复杂化
• 评分主观性：虽然框架结构化，但 STRONG/ADEQUATE/WEAK/MISSING 的判定仍存在一定主观空间
• 改进范围蔓延：用户可能要求超出技能原始设计目标的"改进"，违背"尊重用户设计"原则
• 验证跳过：报告建议的"重跑验证"步骤若被忽略，可能使改进后的 regress 未被捕获

核心用法

improve-skill 是一款元技能（Meta-skill），用于诊断和优化 Factory Droid 生态中的其他技能。其核心工作流程分为六个维度：首先对目标技能的 SKILL.md 及配套文件进行定义清晰度审计，检查指令是否明确、边界情况是否覆盖；其次执行代码库适配分析，扫描当前项目的文件类型、目录结构、命名规范及框架模式，识别技能盲点；第三步进行边缘案例发现，排查特殊文件（如 dotfiles、symlink、非 UTF-8 编码）、框架魔法文件（如 .next/、__generated__/）及 monorepo 模式；第四步评估输出质量，检验生成内容的准确性、一致性与完整性；第五步验证可组合性，包括幂等性、状态管理及跨技能协作能力；最后完成用户体验审查，关注调用便捷性、反馈质量及恢复机制。

用户可通过显式命名（/improve-skill ghost-catalog）、上下文继承（"改进刚才的技能"）或列表选择三种方式触发。输出为标准化的改进报告，包含六维评分卡、优先级排序的改进项、边缘案例清单及具体的 SKILL.md 补丁建议。

显著优点

1. 系统性诊断框架：六维评估模型覆盖技能全生命周期，从静态定义到动态适配，从单点功能到生态协同，避免改进建议的片面性。

2. 项目感知能力：深入分析当前代码库的结构特征，使改进建议高度场景化，而非泛泛而谈。例如针对 Next.js App Router 或 monorepo 模式提出针对性优化。

3. 可执行的输出：所有建议均附带具体行级定位（"line 47 of SKILL.md"）、修复方案及工作量评估（trivial/small/medium/large），降低落地成本。

4. 闭环验证机制：报告生成后支持用户选择改进项，自动完成 SKILL.md 编辑、配套文件更新及回归测试，形成改进闭环。

潜在缺点与局限性

1. 依赖项目规模：大型代码库的边缘案例扫描可能消耗大量 token，极端情况下可能触发上下文长度限制。

2. 主观判断空间：部分评分维度（如 "用户反馈质量"）缺乏量化标准，不同 Agent 的执行一致性可能存在差异。

3. 无历史版本对比：当前设计未内置技能版本化管理，无法自动追踪改进前后的量化指标变化（需手动记录）。

4. T3 来源限制：维护者为社区开发者 SoMaCoSF，非 Factory Droid 官方团队，长期维护承诺存在不确定性。

适合的目标群体

• 技能开发者：希望提升已发布技能的质量评分与生态兼容性
• 技术团队 Lead：负责制定内部技能开发规范及代码审查标准
• DevOps/平台工程师：维护大规模技能库，需要批量诊断工具
• 跨项目迁移者：将技能从旧项目迁移至新技术栈时的适配检查

使用风险

• 性能风险：大型 monorepo 的完整扫描可能耗时较长，建议对超大型仓库启用采样模式
• 误报可能：部分边缘案例（如故意设计的非标准文件）可能被标记为 "unhandled"，需人工复核
• 改进范围约束：该技能专注 "优化既有技能的执行"，而非重新设计技能目的，需求变更场景需配合其他流程
• License 缺失：当前版本未声明开源协议，企业内部二次分发前建议联系维护者明确授权条款