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
1---2name: brooks-lint3description: AI code reviewer grounded in classic software engineering books for catching design smells, coupling issues, and architectural risks.4---567# Brooks Lint89## Overview1011Brooks 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?"1213It 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.1415Named after Fred Brooks, author of *The Mythical Man-Month* — because the hardest bugs are conceptual, not syntactic.1617## The 12 Books1819| 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 |3334## When to Use This Skill3536- Use when you want architectural feedback beyond what linters provide37- Use before major refactors to identify structural debt38- Use when reviewing code that "works but feels wrong"39- Use when onboarding to a codebase to quickly map risk areas40- Use for design reviews before starting a new module or service4142## How It Works4344Brooks Lint applies each book's core principles as a review lens:45461. **Smell detection**: Flags violations of DRY, SRP, Law of Demeter, etc.472. **Coupling analysis**: Identifies tight dependencies and missing abstraction layers483. **Naming critique**: Applies Clean Code naming rules to variables, methods, classes494. **Architecture review**: Checks for DDIA-style data consistency and fault tolerance gaps505. **Stability patterns**: Flags missing timeouts, retries, and circuit breakers (Release It!)516. **Complexity scoring**: Applies APOSD complexity metrics to identify over-engineered sections5253## Installation5455```bash56# Install via Claude Code plugin marketplace57# Search: "brooks-lint" in Claude Code > Extensions5859# Or install via NPX (Antigravity)60npx agentic-awesome-skills --claude61# Then invoke: @brooks-lint62```6364## Examples6566### Example 1: Review a Service Class6768```69@brooks-lint review src/services/PaymentService.ts70```7172**Brooks Lint output:**73```74[Pragmatic Programmer] DRY violation: payment validation logic duplicated in 3 places75[Clean Code] Method processPayment() does 4 things — violates Single Responsibility76[Release It!] No timeout on external payment gateway call — risk of cascade failure77[DDIA] No idempotency key — retry on network error will double-charge78[APOSD] PaymentService knows too much about UserRepository — high coupling79```8081### Example 2: Full Codebase Architecture Review8283```84@brooks-lint analyze the overall architecture of this codebase85```8687### Example 3: Pre-Refactor Review8889```90@brooks-lint what are the biggest design smells in this module before I refactor it?91```9293## Review Categories9495| 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 |105106## Best Practices107108- Run `@brooks-lint` after writing new service layers or data pipelines109- Combine with `@logic-lens` for full coverage: logic bugs + design smells110- Use `@brooks-lint analyze architecture` weekly on growing codebases111- Focus on CRITICAL and HIGH findings first — LOW findings are style suggestions112113## Related Skills114115- `@logic-lens` — Complementary: catches logic bugs; brooks-lint catches design issues116- `@security-auditor` — Specialized security-only deep scan117- `@lint-and-validate` — Style/syntax linting to run alongside design review118119##
sickn33