这是一篇关于「自食其果」的记录。
前几天我在完善 brooks-lint 的 v0.8.5，突然想到：这个工具号称能用 12 本经典工程书的视角审查代码质量——那它自己的代码经不经得起审？
于是我把四个审查 skill 全部对着 brooks-lint 的 validator 脚本跑了一遍。
brooks-lint 是什么
它是一个 Claude Code / Codex CLI / Gemini CLI 插件，能用《人月神话》《重构》《代码整洁之道》等 12 本经典工程书的视角，给代码打出有出处、有依据的"衰变风险"诊断。
不是玄学，每条 finding 都遵循固定格式：症状 → 出处 → 后果 → 补救
四个模式：PR 审查、架构审计、技术债务评估、测试质量审查。
自审过程
依次跑了：
/brooks-audit（架构审计）/brooks-debt（技术债务评估）/brooks-test（测试质量审查）/brooks-review（PR 代码审查）
目标是 scripts/validate-repo.mjs——仓库自己的一致性校验脚本。
发现了什么问题
🔴 R2 散弹式修改 · 高危
书目数量（12）硬编码在三个地方：package.json、validate-repo.mjs、文档。新增一本书需要改四五个文件，典型的 Shotgun Surgery（Fowler《重构》）。
🟡 R1 认知过载 · 中等
250 行的平铺脚本，所有校验逻辑混在一起，没有分层。《整洁代码》里的 Divergent Change 反模式。
🟡 R2 魔法数字 · 中等
风险数量（6 个生产风险 + 6 个测试风险）写成字面量 6，在两个脚本里各出现一次，没有命名常量。
🟡 T6 架构不匹配 · 中等
parseFrontmatterBooks() 内嵌在 validate-repo.mjs 里，测试文件无法在不触发全量校验副作用的情况下单独导入这个函数。可测试性被架构牺牲掉了。
🔵 T5 覆盖率幻觉 · 低
核心 skill 内容检查没有自动化验证，全靠人眼盯着。
修了什么
单一数据源：书单移入 skills/_shared/source-coverage.md 的 YAML frontmatter，validate-repo.mjs 动态读取。加一本书只需改一个文件，Shotgun Surgery 消除。
提取共享模块：新建 scripts/frontmatter.mjs，parseFrontmatterBooks() 独立出来，无副作用导入。
具名常量：PRODUCTION_RISK_COUNT = 6 和 TEST_RISK_COUNT = 6，魔法数字消失。
重构为具名函数：从平铺脚本变成 12 个具名检查函数（checkVersionConsistency、checkSkillsContent、checkEvalSuite 等），调用处读起来像一份清单。
单元测试：新增 scripts/validate-repo.test.mjs，10 个针对 parseFrontmatterBooks 的单元测试，用 Node.js 内置 assert，npm test 直接跑。
Skills 内容 CI：校验器断言每个 SKILL.md 有 ## Setup 和 ## Process，每个 guide 文件引用 Iron Law。
结果
v0.8.5 带着这些修复发布了。
/plugin marketplace add hyhmrright/brooks-lint
/plugin install brooks-lint@brooks-lint-marketplace
最有意思的地方：工具发现的问题都是真实的，修起来也很直接。因为 brooks-lint 的每条 finding 都有书上的出处，所以你能判断它对不对——而不是盲目接受 AI 的建议。
GitHub：hyhmrright/brooks-lint
支持 Claude Code、Codex CLI、Gemini CLI，MIT 协议，欢迎 star ⭐
