Code Design Review

Role: A pre-implementation design-quality review for solutions that involve code changes. It evaluates whether the proposed code is well-crafted — maintainable, testable, properly decoupled — not just whether it solves the problem. It is the code-specialized companion to solution-review (which handles decision-level review for any solution type). PDCA hosts declare this skill in frontmatter dependencies and invoke it after a prerequisite check (the host aborts at startup if this skill is missing).

Detailed framework entries (author, year, thresholds, source) and the full blocking/non-blocking criteria live in reference.md.

Why this skill exists

A code solution can be correct (it solves the problem) and still be poorly designed — introducing coupling that makes the next change harder, complexity that exceeds what the problem demands, or tech debt the team does not know it holds. These design failures are invisible to "does it work?" testing; they surface months later as maintenance pain, regression cascades, and fear of change.

AI-era premise: when implementation is cheap (including AI-assisted coding), "it works and is near-term maintainable" is a weak bar. Architectural elegance and long-term maintainability must carry higher review weight — rewriting a better structure often costs less than living with the debt.

This skill applies software-engineering theory — not opinion — to evaluate code design quality before a single line is written. Every check item traces to a named framework (Brooks, Myers, Yourdon-Constantine, Fowler, McCabe, ISO 25010, Clean Architecture, OWASP). The meta-lesson:

Code that works but is poorly designed becomes tomorrow's maintenance crisis. Review design quality before implementation, when changing direction is still cheap — and do not defer a clearly better architecture just because shipping the weaker one is easy.

When to use

Strong signals (any one):