Architect Code with Classic Engineering Principles

Brooks Lint reviews code through the lens of 12 classic software engineering books, synthesizing their principles into structured feedback that catches design smells, tight coupling, missing abstractions, and architectural risks that linters and typical AI tools miss - named after Fred Brooks (The Mythical Man-Month) because the hardest bugs are conceptual, not syntactic. The 12 books and their applied principles: 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), The Art of UNIX Programming (modularity, composability, rule of least surprise), and Extreme Programming Explained (YAGNI, simple design, collective ownership). It runs six review passes: smell detection (DRY, SRP, Law of Demeter violations), coupling analysis, Clean-Code-style naming critique, DDIA-style data-consistency and fault-tolerance architecture review, Release-It!-style stability-pattern checks (missing timeouts, retries, circuit breakers), and APOSD-based complexity scoring for over-engineered sections. Install via the Claude Code plugin marketplace, or via NPX:

npx agentic-awesome-skills --claude

then invoke with @brooks-lint.

Use this skill for architectural feedback beyond what linters provide, before major refactors to identify structural debt, when reviewing code that "works but feels wrong," when onboarding to a codebase to map risk areas, or for design reviews before starting a new module or service.

Given a file, module, or whole-codebase target (@brooks-lint review <path>, analyze the overall architecture, or ask what the biggest design smells are before a refactor), output is a list of findings each tagged with the source book, such as a DRY violation flagged from Pragmatic Programmer, a Single-Responsibility violation from Clean Code, a missing-timeout risk from Release It!, a missing-idempotency-key risk from DDIA, or a high-coupling finding from A Philosophy of Software Design (APOSD). Eight review categories organize findings: DRY/Duplication, Naming, Coupling, Stability, Data Integrity, Complexity, Legacy Debt, and Domain Clarity, each mapped to the specific books that inform it.

Complementary to @logic-lens (catches logic bugs, where Brooks Lint catches design issues), @security-auditor (specialized security-only deep scan), and @lint-and-validate (style/syntax linting to run alongside design review). Best practice is running it after writing new service layers or data pipelines, weekly for architecture analysis on growing codebases, and prioritizing CRITICAL/HIGH findings over LOW (style-suggestion) findings.

Engineers who want book-grounded architectural and design review beyond linter-level checks - catching conceptual issues like missing abstractions, stability gaps, and data-integrity risks - as a complement to, not a replacement for, human design review on production-critical decisions.