Brooks Lint
Overview
Brooks Lint is a Claude Code skill that reviews your code through the lens of 12 classic software engineering books. Instead of checking style rules, it asks: "What would the authors of The Pragmatic Programmer, Clean Code, and Designing Data-Intensive Applications say about this code?"
It synthesizes the principles from landmark engineering books into actionable, structured feedback — catching design smells, tight coupling, missing abstractions, and architectural risks that linters and AI tools typically miss.
Named after Fred Brooks, author of The Mythical Man-Month — because the hardest bugs are conceptual, not syntactic.
The 12 Books
| Book |
Key Principles Applied |
| The Pragmatic Programmer |
DRY, orthogonality, tracer bullets |
| Clean Code |
Naming, function size, comment clarity |
| The Mythical Man-Month |
Conceptual integrity, second-system effect |
| Designing Data-Intensive Applications |
Data consistency, fault tolerance, scalability |
| A Philosophy of Software Design |
Deep modules, information hiding, complexity |
| Refactoring |
Code smells, extract method, encapsulation |
| Working Effectively with Legacy Code |
Seams, characterization tests, dependency breaking |
| Domain-Driven Design |
Ubiquitous language, bounded contexts, aggregates |
| Release It! |
Stability patterns, timeouts, bulkheads, circuit breakers |
| Structure and Interpretation of Computer Programs |
Abstraction, recursion, metalinguistic abstraction |
| The Art of UNIX Programming |
Modularity, composability, rule of least surprise |
| Extreme Programming Explained |
YAGNI, simple design, collective ownership |
When to Use This Skill
- Use when you want architectural feedback beyond what linters provide
- Use before major refactors to identify structural debt
- Use when reviewing code that "works but feels wrong"
- Use when onboarding to a codebase to quickly map risk areas
- Use for design reviews before starting a new module or service
How It Works
Brooks Lint applies each book's core principles as a review lens:
- Smell detection: Flags violations of DRY, SRP, Law of Demeter, etc.
- Coupling analysis: Identifies tight dependencies and missing abstraction layers
- Naming critique: Applies Clean Code naming rules to variables, methods, classes
- Architecture review: Checks for DDIA-style data consistency and fault tolerance gaps
- Stability patterns: Flags missing timeouts, retries, and circuit breakers (Release It!)
- Complexity scoring: Applies APOSD complexity metrics to identify over-engineered sections
Installation
# Install via Claude Code plugin marketplace
# Search: "brooks-lint" in Claude Code > Extensions
# Or install via NPX (Antigravity)
npx agentic-awesome-skills --claude
# Then invoke: @brooks-lint
Examples
Example 1: Review a Service Class
@brooks-lint review src/services/PaymentService.ts
Brooks Lint output:
[Pragmatic Programmer] DRY violation: payment validation logic duplicated in 3 places
[Clean Code] Method processPayment() does 4 things — violates Single Responsibility
[Release It!] No timeout on external payment gateway call — risk of cascade failure
[DDIA] No idempotency key — retry on network error will double-charge
[APOSD] PaymentService knows too much about UserRepository — high coupling
Example 2: Full Codebase Architecture Review
@brooks-lint analyze the overall architecture of this codebase
Example 3: Pre-Refactor Review
@brooks-lint what are the biggest design smells in this module before I refactor it?
Review Categories
| Category |
Books Applied |
What It Catches |
| DRY / Duplication |
PP, Refactoring |
Copy-paste code, shared logic not extracted |
| Naming |
Clean Code, DDD |
Unclear names, domain language violations |
| Coupling |
APOSD, PP |
Tight dependencies, missing interfaces |
| Stability |
Release It! |
Missing timeouts, no retry logic, no circuit breakers |
| Data Integrity |
DDIA |
Race conditions, non-idempotent operations |
| Complexity |
APOSD, SICP |
Over-engineering, unnecessary abstraction |
| Legacy Debt |
WELC |
Hard-to-test code, missing seams |
| Domain Clarity |
DDD, XP |
Anemic models, missing bounded contexts |
Best Practices
- Run
@brooks-lint after writing new service layers or data pipelines
- Combine with
@logic-lens for full coverage: logic bugs + design smells
- Use
@brooks-lint analyze architecture weekly on growing codebases
- Focus on CRITICAL and HIGH findings first — LOW findings are style suggestions
Related Skills
@logic-lens — Complementary: catches logic bugs; brooks-lint catches design issues@security-auditor — Specialized security-only deep scan@lint-and-validate — Style/syntax linting to run alongside design review
Additional Resources
Limitations
Use this skill only when the task clearly matches the scope described above (design review and architectural analysis). Brooks Lint applies AI-powered analysis grounded in established engineering principles. It should complement — not replace — human design review for production-critical decisions. Results reflect the principles of the 12 source books and may not apply to all architectural styles or domains.
Source: sickn33/agentic-awesome-skills → skills/brooks-lint/SKILL.md
Also appears in: sickn33/agentic-awesome-skills/plugins/agentic-awesome-skills/skills/brooks-lint/SKILL.md, sickn33/agentic-awesome-skills/plugins/agentic-awesome-skills-claude/skills/brooks-lint/SKILL.md
1---2name: brooks-lint3description: AI code reviewer grounded in classic software engineering books for catching design smells, coupling issues, and architectural risks.4---5
6
7# Brooks Lint
8
9## Overview
10
11Brooks Lint is a Claude Code skill that reviews your code through the lens of 12 classic software engineering books. Instead of checking style rules, it asks: "What would the authors of *The Pragmatic Programmer*, *Clean Code*, and *Designing Data-Intensive Applications* say about this code?"
12
13It synthesizes the principles from landmark engineering books into actionable, structured feedback — catching design smells, tight coupling, missing abstractions, and architectural risks that linters and AI tools typically miss.
14
15Named after Fred Brooks, author of *The Mythical Man-Month* — because the hardest bugs are conceptual, not syntactic.
16
17## The 12 Books
18
19| Book | Key Principles Applied |
20|------|----------------------|
21| *The Pragmatic Programmer* | DRY, orthogonality, tracer bullets |
22| *Clean Code* | Naming, function size, comment clarity |
23| *The Mythical Man-Month* | Conceptual integrity, second-system effect |
24| *Designing Data-Intensive Applications* | Data consistency, fault tolerance, scalability |
25| *A Philosophy of Software Design* | Deep modules, information hiding, complexity |
26| *Refactoring* | Code smells, extract method, encapsulation |
27| *Working Effectively with Legacy Code* | Seams, characterization tests, dependency breaking |
28| *Domain-Driven Design* | Ubiquitous language, bounded contexts, aggregates |
29| *Release It!* | Stability patterns, timeouts, bulkheads, circuit breakers |
30| *Structure and Interpretation of Computer Programs* | Abstraction, recursion, metalinguistic abstraction |
31| *The Art of UNIX Programming* | Modularity, composability, rule of least surprise |
32| *Extreme Programming Explained* | YAGNI, simple design, collective ownership |
33
34## When to Use This Skill
35
36- Use when you want architectural feedback beyond what linters provide
37- Use before major refactors to identify structural debt
38- Use when reviewing code that "works but feels wrong"
39- Use when onboarding to a codebase to quickly map risk areas
40- Use for design reviews before starting a new module or service
41
42## How It Works
43
44Brooks Lint applies each book's core principles as a review lens:
45
461. **Smell detection**: Flags violations of DRY, SRP, Law of Demeter, etc.
472. **Coupling analysis**: Identifies tight dependencies and missing abstraction layers
483. **Naming critique**: Applies Clean Code naming rules to variables, methods, classes
494. **Architecture review**: Checks for DDIA-style data consistency and fault tolerance gaps
505. **Stability patterns**: Flags missing timeouts, retries, and circuit breakers (Release It!)
516. **Complexity scoring**: Applies APOSD complexity metrics to identify over-engineered sections
52
53## Installation
54
55```bash
56# Install via Claude Code plugin marketplace
57# Search: "brooks-lint" in Claude Code > Extensions
58
59# Or install via NPX (Antigravity)
60npx agentic-awesome-skills --claude
61# Then invoke: @brooks-lint
62```
63
64## Examples
65
66### Example 1: Review a Service Class
67
68```
69@brooks-lint review src/services/PaymentService.ts
70```
71
72**Brooks Lint output:**
73```
74[Pragmatic Programmer] DRY violation: payment validation logic duplicated in 3 places
75[Clean Code] Method processPayment() does 4 things — violates Single Responsibility
76[Release It!] No timeout on external payment gateway call — risk of cascade failure
77[DDIA] No idempotency key — retry on network error will double-charge
78[APOSD] PaymentService knows too much about UserRepository — high coupling
79```
80
81### Example 2: Full Codebase Architecture Review
82
83```
84@brooks-lint analyze the overall architecture of this codebase
85```
86
87### Example 3: Pre-Refactor Review
88
89```
90@brooks-lint what are the biggest design smells in this module before I refactor it?
91```
92
93## Review Categories
94
95| Category | Books Applied | What It Catches |
96|----------|--------------|-----------------|
97| **DRY / Duplication** | PP, Refactoring | Copy-paste code, shared logic not extracted |
98| **Naming** | Clean Code, DDD | Unclear names, domain language violations |
99| **Coupling** | APOSD, PP | Tight dependencies, missing interfaces |
100| **Stability** | Release It! | Missing timeouts, no retry logic, no circuit breakers |
101| **Data Integrity** | DDIA | Race conditions, non-idempotent operations |
102| **Complexity** | APOSD, SICP | Over-engineering, unnecessary abstraction |
103| **Legacy Debt** | WELC | Hard-to-test code, missing seams |
104| **Domain Clarity** | DDD, XP | Anemic models, missing bounded contexts |
105
106## Best Practices
107
108- Run `@brooks-lint` after writing new service layers or data pipelines
109- Combine with `@logic-lens` for full coverage: logic bugs + design smells
110- Use `@brooks-lint analyze architecture` weekly on growing codebases
111- Focus on CRITICAL and HIGH findings first — LOW findings are style suggestions
112
113## Related Skills
114
115- `@logic-lens` — Complementary: catches logic bugs; brooks-lint catches design issues
116- `@security-auditor` — Specialized security-only deep scan
117- `@lint-and-validate` — Style/syntax linting to run alongside design review
118
119## Additional Resources
120
121- [GitHub Repository](https://github.com/hyhmrright/brooks-lint)
122- [Dev.to Article: I Synthesized 12 Classic Engineering Books into an AI Code Reviewer](https://dev.to/hyhmrright/i-synthesized-12-classic-engineering-books-into-an-ai-code-reviewer-heres-what-it-caught-3ed1)
123- [Related skill: logic-lens](https://github.com/hyhmrright/logic-lens)
124
125## Limitations
126
127Use this skill only when the task clearly matches the scope described above (design review and architectural analysis). Brooks Lint applies AI-powered analysis grounded in established engineering principles. It should complement — not replace — human design review for production-critical decisions. Results reflect the principles of the 12 source books and may not apply to all architectural styles or domains.
128
129---
130
131**Source:** [`sickn33/agentic-awesome-skills`](https://github.com/sickn33/agentic-awesome-skills) → `skills/brooks-lint/SKILL.md`
132
133**Also appears in:** `sickn33/agentic-awesome-skills/plugins/agentic-awesome-skills/skills/brooks-lint/SKILL.md`, `sickn33/agentic-awesome-skills/plugins/agentic-awesome-skills-claude/skills/brooks-lint/SKILL.md`
thedixitjain