如何将 Quality Playbook 适配到 Hermes：提取，而非复制

当你遇到一个近万安装量、479 行指令集的精心制作的第三方技能时，直觉是把整个东西搬过来。越多越好，对吧？

错了。技能适配的艺术是减法，不是加法。它是提取真正新颖的内容，丢弃你现有生态已经处理好的部分。这是我们将 Andrew Stellman 的 quality-playbook-generator 适配到 Hermes 的故事——最终从一个 479 行的庞然大物中创建了两个技能，同时留下了四个冗余产物。

原材料

Quality Playbook Generator（v1.2.0，来自 github/awesome-copilot，9.5K 安装量）是一项令人印象深刻的工作。其 479 行的 SKILL.md 编排了一个多阶段流程，产生六份文件：质量宪章、功能测试、代码审查协议、集成测试协议、"三巨头"规范审计，以及 AGENTS.md 引导文件。

核心创新是该技能所称的"寻找骨架"——系统性地搜索防御性代码模式，作为过去失败的证据。每个 try/except、空值检查和重试循环都是代码库在低语其历史。这种取证式的质量方法真正新颖且语言无关。它适用于 Python、Java、Scala、TypeScript、Go 和 Rust。

但完整的操作手册还生成了四个协议文档，我们现有的技能图已经覆盖：

代码审查协议 → 由 code-review-and-quality 覆盖
集成测试协议 → 由 testing-patterns 覆盖
规范审计方法论 → 由 security-auditor 和 code-reviewer 覆盖
质量宪章 → 与 domain-glossary 和 documentation-and-adrs 重叠

将这些复制为独立协议会创建一个平行的质量系统，与现有图竞争而非集成——这是我们明确避免的反模式。

方法论：成本 → 提取 → 组合 → 集成

第三方技能适配管线 — Hermes 方法论

我们的第三方技能适配流程遵循严格的顺序：

步骤 1：成本模型检查（源码审查之前）

这排在第一位，不是最后。Quality Playbook 不需要 API 密钥、云服务或订阅费。它完全在本地代码上运行。评分：免费 SaaS。继续。

如果这一步揭示出付费 API 要求，我们会立即停止——这就是 Skywork 规则。七个技能因每月 19.99 美元被整合后移除，无论其 7.9/10 的技术评分如何。

步骤 2：源码审查与安全审计

阅读 479 行 SKILL.md 的每一行。检查：硬编码凭据、外部数据流、许可证兼容性、权限提升向量。Quality Playbook 是干净的——Andrew Stellman 以 MIT 许可发布，无网络调用，无凭据处理。唯一的"依赖"是假设 AI 智能体能运行 grep 和读取文件。

步骤 3：多维度评估

对每个交付物，对照现有替代方案评分：

交付物	新颖性	现有覆盖	操作
防御模式审计	高——独特的取证方法	无	提取
适用性场景	高——基于代码证据	无	提取
QUALITY.md 宪章	中——与领域文档重叠	domain-glossary, documentation-and-adrs	丢弃（整合指针）
功能测试生成	低——已覆盖	test-driven-development, testing-patterns	丢弃
代码审查协议	低——已覆盖	code-review-and-quality	丢弃
三巨头审计	中——多模型想法有趣	code-reviewer, security-auditor	丢弃（在现有技能中引用方法）

步骤 4：层级映射

提取的取证方法论自然映射到两个层级：

原子：defensive-code-audit — 单一用途、确定性的 grep 和分类工作流。语言无关模式、风险领域分类、场景生成格式。无子技能依赖。
分子：codebase-quality-forensics — 将 defensive-code-audit 与现有 domain-glossary、code-review-and-quality 和 documentation-and-adrs 串联。编排完整的取证管道：发现 → 防御模式挖掘 → 质量态势报告 → 呈现与迭代。声明 requires_skills 和 feeds_into 边。

步骤 5：重写，绝不复制粘贴

第三方技能描述通常是关键词堆砌（quality-playbook 的描述超过 800 个字符，列出每个可能的触发短语）。Hermes 描述是简洁的："Use when..."格式，低于 200 个字符。

正文重写同样重要。原始 479 行的 SKILL.md 包含生成 PowerPoint 风格报告和基于浏览器的审查查看器的详细指令——这些功能需要我们没有也不会使用的基础设施。我们适配的版本分别为 150 行和 250 行，各自专注于执行而非呈现。

步骤 6：脚本处理

Quality Playbook 不包含脚本——只有参考文件（defensive_patterns.md、schema_mapping.md、constitution.md 等）。这些是方法论指南，不是可执行代码。我们的适配将 grep 模式直接嵌入技能正文中，而不是将它们外部化为参考文件。这些模式就是技能本身——将它们隐藏在参考指针后面只会增加间接性而没有价值。

步骤 7：图集成

最后也是最关键的步骤：将新技能接入现有图。

defensive-code-audit（原子）
    feeds_into → codebase-quality-forensics

codebase-quality-forensics（分子）
    requires_skills → [defensive-code-audit, code-review-and-quality, domain-glossary, documentation-and-adrs]
    feeds_into → [coding-build-ship, testing-patterns]

feeds_into 边是集成点。coding-build-ship 现在可以在实现前参考取证发现。testing-patterns 可以为发现的失败模式生成回归测试。新技能不是与现有图竞争——它们扩展它。

我们留下的（以及为什么这是好事）

原始操作手册生成六个文件。我们适配了恰好一个能力（防御模式挖掘）和一个工作流（取证管道编排）。其他一切已经被覆盖：

功能测试 → test-driven-development 以 RED-GREEN-REFACTOR 纪律处理测试生成。从不同哲学添加并行功能测试生成会混乱选择哪种方法。
代码审查协议 → code-review-and-quality 已经包含护栏（行号、阅读函数体、声称前 grep）。并行审查协议文档增加文档开销而无新能力。
集成测试协议 → testing-patterns 覆盖集成测试策略。quality-playbook 生成 markdown 协议文档的方法是一种呈现选择，不是能力——也不是我们采用的选择。
三巨头审计 → 多模型审计的想法真正有趣，但需要基础设施（三种不同的 AI 模型、独立运行、结果合并）。我们的 code-reviewer 和 security-auditor 技能以更少仪式感覆盖同样的表面区域。
质量宪章 → domain-glossary 在会话间维护领域术语。documentation-and-adrs 记录架构决策。独立的 QUALITY.md 增加了碎片化而没有新信息。

教训：第三方技能经常将"我们做什么"与"我们如何呈现所做的事"混为一谈。方法论是有价值的；呈现格式是实现细节。提取方法论，将其集成到现有图中，丢弃呈现产物。

结果与验证

创建后，两个技能都通过组合完整性检查：

前置元数据从字节 0 开始，具有有效的 --- 分隔符
name 字段是小写 + 连字符，低于 64 个字符
defensive-code-audit 有空的 requires_skills: []（原子正确）
codebase-quality-forensics 列出四个依赖技能（分子正确）
扩展图中无循环依赖
两个技能都出现在 software-development 下的 skills_list 中

适配也通过我们的安全检查清单验证：

无认证令牌、网络调用或外部依赖
无遥测、追踪或分析代码
文件访问限于本地项目目录
MIT 许可证允许集成

最终状态：两个紧密聚焦的技能扩展了我们现有图的取证和质量覆盖面。无重复。无碎片化。无平行质量系统竞争注意力。只有对已有内容的干净、可组合扩展。

这就是我们将应用于未来每次第三方技能集成的方法论。提取新颖的内容。丢弃你的图已经处理的。用显式边将提取内容接入图中。发布。