Brooks design lint
Skill findscripter/everything-skills/02-engineering/brooks-design-lint
当需要超越 linter 的架构与设计层审查（重构前、新模块设计评审、接手陌生代码、"能跑但感觉不对"的代码）时使用；以 12 本经典软工书籍为视角，产出按书籍/严重度分级的设计坏味、耦合、稳定性与数据一致性问题清单及改进建议；不适用于语法/风格 lint、纯逻辑 bug 排查、安全专项扫描，也不替代人工设计评审；触发词：设计审查、架构评审、重构前体检、代码坏味、耦合分析、Brooks LintFrom its SKILL.md
npx -y skills add findscripter/everything-skills --skill brooks-design-lintAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its file declares
Copied from the file, not written here
The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
6.4 KB, ~2.0k tokens by cl100k_base, as published. Nobody here has run it
以 Fred Brooks 命名（《人月神话》作者）——因为最难的 bug 是概念性的，而非语法性的。本技能不查风格规则，而是以 12 本经典软工书籍为审查视角，回答："《程序员修炼之道》《代码整洁之道》《数据密集型应用系统设计》的作者们会怎么评价这段代码？"——捕捉 linter 与常规 AI 工具容易漏掉的设计坏味、紧耦合、缺失抽象与架构风险。
何时使用
适用：
- 想要超出 linter 范围的架构/设计层反馈。
- 大型重构前，定位结构性技术债。
- 审查"能跑但感觉不对"的代码。
- 接手陌生代码库，快速绘制风险地图。
- 启动新模块/服务前的设计评审。
不该用（负边界）：
- 语法/风格 lint（交给 ESLint、Prettier 等）。
- 纯逻辑 bug 排查（属于功能正确性，另用逻辑审查工具）。
- 安全专项深扫（用安全审计技能）。
- 生产关键决策：本技能是 AI 辅助，应补充而非替代人工设计评审；结论受 12 本源书视角约束，未必适配所有架构风格或领域。
步骤
- 划定范围：单文件 / 单模块 / 整体架构，明确审查目标（如"重构前找最大设计坏味"）。
- 用 Read / Grep / Glob 读取目标代码与其依赖边界。
- 以下面 6 个视角逐项扫描，对每条发现标注【书名】+ 严重度（CRITICAL / HIGH / MEDIUM / LOW）。
- 优先输出 CRITICAL 与 HIGH；LOW 仅作风格建议。
- 每条发现给出"问题定位 + 违背的原则 + 可执行的改进方向"。
6 个审查视角
- 坏味检测：违反 DRY、SRP、迪米特法则（Law of Demeter）等。
- 耦合分析：紧依赖、缺失抽象层/接口。
- 命名批判：用《代码整洁之道》命名规则审视变量/方法/类，并对照 DDD 领域语言。
- 架构审查：DDIA 视角的数据一致性、幂等性、容错缺口。
- 稳定性模式：缺失超时、重试、熔断器、舱壁（《Release It!》）。
- 复杂度评分：用《软件设计的哲学》(APOSD) 复杂度度量识别过度设计/不必要抽象。
12 本书与对应原则
| 书 | 应用的关键原则 |
|---|---|
| 程序员修炼之道 (PP) | DRY、正交性、曳光弹 |
| 代码整洁之道 (Clean Code) | 命名、函数大小、注释清晰度 |
| 人月神话 (MMM) | 概念完整性、第二系统效应 |
| 数据密集型应用系统设计 (DDIA) | 数据一致性、容错、可扩展性 |
| 软件设计的哲学 (APOSD) | 深模块、信息隐藏、复杂度 |
| 重构 (Refactoring) | 代码坏味、提炼函数、封装 |
| 修改代码的艺术 (WELC) | 接缝、特征测试、打破依赖 |
| 领域驱动设计 (DDD) | 统一语言、限界上下文、聚合 |
| Release It! | 稳定性模式：超时、舱壁、熔断器 |
| 计算机程序的构造和解释 (SICP) | 抽象、递归、元语言抽象 |
| UNIX 编程艺术 | 模块化、可组合、最小惊讶原则 |
| 解析极限编程 (XP) | YAGNI、简单设计、集体所有权 |
审查类目速查
| 类目 | 涉及书 | 捕捉什么 |
|---|---|---|
| DRY/重复 | PP、Refactoring | 复制粘贴、未提炼的共享逻辑 |
| 命名 | Clean Code、DDD | 含混命名、违反领域语言 |
| 耦合 | APOSD、PP | 紧依赖、缺失接口 |
| 稳定性 | Release It! | 缺超时/重试/熔断 |
| 数据完整性 | DDIA | 竞态、非幂等操作 |
| 复杂度 | APOSD、SICP | 过度工程、不必要抽象 |
| 遗留债 | WELC | 难测代码、缺失接缝 |
| 领域清晰度 | DDD、XP | 贫血模型、缺失限界上下文 |
指令
- 审查单个服务类：
review src/services/PaymentService.ts - 整体架构审查：
analyze the overall architecture of this codebase - 重构前体检：
what are the biggest design smells in this module before I refactor it?
示例
输入：review src/services/PaymentService.ts
输出（每条标注书籍来源）：
[程序员修炼之道] DRY 违规：支付校验逻辑在 3 处重复
[代码整洁之道] processPayment() 做了 4 件事——违反单一职责
[Release It!] 调用外部支付网关无超时——级联失败风险
[DDIA] 缺幂等键——网络错误重试会重复扣款
[APOSD] PaymentService 对 UserRepository 知道太多——高耦合
注意事项
- 优先处理 CRITICAL / HIGH 发现，LOW 属风格建议。
- 在新增服务层或数据管道后即跑一次设计审查；成长中的代码库可每周做一次整体架构审查。
- 与逻辑审查互补使用：逻辑审查抓功能 bug，本技能抓设计问题，两者覆盖更全。
- 本技能是 AI 辅助分析，结论受 12 本源书原则约束，未必适配所有架构风格/领域，生产关键决策仍需人工评审把关。
互见
- 逻辑/功能正确性审查技能：抓逻辑 bug，与本技能形成"逻辑 bug + 设计坏味"双覆盖。
- 安全审计技能：安全专项深扫。
- 风格/语法 lint：与设计审查并行运行。
- code-review / review：可在 PR 流程中配合本技能的设计视角。
采编自 sickn33/antigravity-awesome-skills（原 skill: brooks-lint，作者 hyhmrright，许可证 MIT）。
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.