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.
| 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 |
Brooks Lint applies each book's core principles as a review lens:
# Install via Claude Code plugin marketplace
# Search: "brooks-lint" in Claude Code > Extensions
# Or install via NPX (Antigravity)
npx antigravity-awesome-skills --claude
# Then invoke: @brooks-lint
@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
@brooks-lint analyze the overall architecture of this codebase
@brooks-lint what are the biggest design smells in this module before I refactor it?
| 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 |
@brooks-lint after writing new service layers or data pipelines@logic-lens for full coverage: logic bugs + design smells@brooks-lint analyze architecture weekly on growing codebases@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 reviewUse 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.