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

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:

1. Smell detection: Flags violations of DRY, SRP, Law of Demeter, etc.
2. Coupling analysis: Identifies tight dependencies and missing abstraction layers
3. Naming critique: Applies Clean Code naming rules to variables, methods, classes
4. Architecture review: Checks for DDIA-style data consistency and fault tolerance gaps
5. Stability patterns: Flags missing timeouts, retries, and circuit breakers (Release It!)
6. 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

Best Practices

…