通用Skill构建大师

为什么需要这个技能

把领域知识「翻译」成 Skill 时，最常见的失败方式是把 SKILL.md 当成知识仓库：调研结果、规则、示例一股脑写进去，主体膨胀到上千行，模型的注意力被稀释，真正关键的约束反而埋在中段被忽略。另一种失败是作者自己写、自己审，规则写得好不好全凭自觉，盲区永远存在。更隐蔽的问题是：Skill 在对话里「看起来完成了」，但文件从未落到磁盘，下次开工一切重来。

这个技能针对的就是这三件事。

它如何工作

核心设计是 Builder 与 Evaluator 角色分离。Builder 负责调研、设计、编写；Evaluator 独立评审，只输出修改指令、不动手改内容。规则集、Skill 草稿、最终稿等关键产出必须通过 ≥3 轮 Builder→Evaluator 迭代才能放行，最多 5 轮——超出仍未收敛，就停下来向用户报告分歧点，由人裁决。

工作流共 8 个阶段：

• PHASE 1 需求解析：需求卡片 + 至少 3 个竞品的深度分析 + 知识分类表。知识被分成四类：领域独有（写入）、品味校准（只写正反例）、通用知识（不写入）、高频失败模式（写成防护规则）。
• PHASE 2 架构设计：选择工作流模式（阶段链+门控、维度并行+汇总、搜索综合+修订、状态机+路由），预估 token 预算。硬规则超过 25 条、阶段 ≥4 且职责不重叠、存在 ≥2 个独立质检维度时，必须拆分为 orchestrator + worker 的多 Skill 体系。每个阶段都要定义显式输出物——结论块、文件片段或通过/失败判定，防止模型「内心完成」跳过步骤。
• PHASE 3 规则与示例工程：识别让产出从「正确」到「惊艳」的 1-2 个杠杆，设为 P0 首条。每条规则用条件-动作格式，正向表述占比 ≥70%。每组示例 3-5 个、覆盖 ≥3 种子类型、正反例成对。
• PHASE 4-6：规则质量迭代、Skill 组装、实效验证迭代，各 ≥3 轮。组装后有 6 项注意力位置检查：P0 出现在前 20% 行数内、在后 20% 复述、中段有刷新提醒、质检阶段有角色切换声明等。
• PHASE 7 工程质量审计：8 个维度打分（架构、注意力、规则、知识、示例、工作流、输出、鲁棒性），总分 ≥75 且无红色维度才算通过。
• PHASE 8 交付：第一个动作是通过工具把 SKILL.md（含 YAML frontmatter）写入 .codebuddy/skills/ 目录，拿到工具的写入确认才算交付，口头宣称「已完成」无效。

适用边界

这个技能不是领域知识的来源，它只能帮你把已有的领域理解结构化，知识本身仍需用户提供或自行调研。迭代轮次有硬上限（≤5 轮），超过之后流程会强制停下，剩余分歧要人工解决。交付强依赖环境中的文件写入工具，没有 write_to_file 能力的环境里 PHASE 8 无法闭环。另外，规则数量与主体行数的约束是为单 Skill 设计的，复杂领域应当在 PHASE 2 就判定拆分，而不是事后精简。