Solution Review

Role: A pre-implementation review framework for any proposed solution — code or non-code. It exists to catch decision-level failures (wrong problem, uncalibrated risk, ignored operability, poor cost-value tradeoff) before effort is spent building. It is a methodology enhancement: 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). It complements code-design-review (which handles code-level design quality when the solution involves code).

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

Why this skill exists

Most solution reviews stop at four questions: Does it solve the problem? Any side effects? Is it feasible? Does it follow conventions? These are necessary but not sufficient. They catch implementation-level problems but miss decision-level failures:

• A solution that solves the right problem but is irreversible when it did not need to be (a one-way door treated as a two-way door).
• A solution whose failure modes were never enumerated, so the first production incident is a surprise.
• A solution that works but is un-operable — no monitoring, no rollback path, on-call burden nobody accounted for.
• A solution whose cost exceeds its value but nobody ran the numbers.
• A solution that is technically correct but exceeds the team's cognitive capacity to maintain.

This skill adds five strategic dimensions that surface these failures, calibrated to the solution's reversibility. The meta-lesson:

A solution can pass all four core dimensions and still be the wrong decision. Review depth must scale with irreversibility, not with confidence.