Enforce Clean Code and Architecture Principles

Uncle Bob Craft applies Robert C. Martin's body of work - Clean Code, Clean Architecture, The Clean Coder, Clean Agile, and design-pattern discipline - to code review and production. It is complementary to a separate @clean-code skill (which covers naming, functions, comments, formatting from the Clean Code book specifically) and to the project's linter/formatter, which it does not replace: this skill provides craft and design criteria only, not syntax or style enforcement. It evaluates structure, dependencies, SOLID principles in context, code smells, and professional practices.

Use it for code review (Dependency Rule, boundaries, SOLID, smell heuristics, concrete refactor suggestions), refactoring decisions (what to extract, where to draw boundaries, whether a design pattern is justified), architecture discussion (layer boundaries, dependency direction, separation of concerns), design-pattern evaluation (correct use versus cargo-cult or overuse), estimation and professionalism (saying no, sustainable pace, three-point estimates from The Clean Coder), and agile-process discussion (Iron Cross, TDD, refactoring, pair programming from Clean Agile). Do not use it to replace or override the project's linter, formatter, or automated tests.

Seven named code smells to scan for: Rigidity (small change forces many edits), Fragility (changes break unrelated areas), Immobility (hard to reuse elsewhere), Viscosity (easy to hack, hard to do right), Needless complexity (speculative or unused abstraction), Needless repetition (DRY violated), and Opacity (hard to understand). A review walks through boundaries and the Dependency Rule (dependencies must point inward - use cases shouldn't depend on UI or DB details), SOLID in context, a smell scan with file/area references, one or two concrete refactor suggestions (e.g. "extract this into a function named X", "introduce an interface so this layer doesn't depend on the concrete DB client"), and a check for tests and professionalism. A copy-pasteable review prompt template is included, along with a before/after example extracting an opaque conditional into a named apply_discount function.

Design-pattern guidance follows a rule of thumb: introduce a pattern on the third duplication or second reason to change, not preemptively - cargo-cult signs include pattern names baked into every class, delegation-only layers with no real logic, and patterns that make simple code harder to follow. Detailed source-specific reference material lives in reference.md and per-topic files (clean-architecture.md, clean-coder.md, clean-agile.md, design-patterns.md).

Developers and reviewers who want architecture- and design-level code review grounded in a specific, named body of craft principles rather than generic "looks fine to me" feedback - used alongside, not instead of, linting and automated tests.