review-a-design skill | PlugMCP

review-a-design skill | PlugMCP

Problem lens — Is the stated problem the real problem, or a symptom of one upstream? Whose problem is it, and what evidence says it hurts today (not hypothetically)? A design aimed at a symptom is unsound however elegant. Failure it catches: solving the wrong problem beautifully.
Goal-derivation lens — Does the design follow from the stated goals, or were the goals reverse-engineered to justify a design chosen first? Read the goals, then read the design cold: could you have predicted this design from these goals? If the design has a feature no goal demands, either the goal is unstated or the feature is scope. Failure it catches: solution-first rationalization.
Alternatives lens — Are the alternatives real, or strawmen? Take the strongest version of the rejected option — steelman it — and check whether the document engages with that, or with a weak caricature. An Alternatives section that dismisses each option in one dismissive sentence is a tell. Failure it catches: a foregone conclusion dressed as a comparison.
Constraint lens — Which constraints are hard, and which are inherited habit? Hard: physics, compliance, a one-way door already walked through, a contract with a downstream team. Soft: "we've always done it this way", a limit of the current tool, a deadline that could move. A design that treats a soft constraint as hard is under-imagined and probably larger than it needs to be. Failure it catches: unnecessary complexity justified by a fake wall.
Cost lens — What does this design foreclose, and what does it hand the team every week for the next three years? Name the ongoing obligation: the migration that can't be undone, the schema that now needs backfilling forever, the on-call surface. Blast radius is not just the launch; it's the maintenance tail. Failure it catches: a cheap-looking design with an expensive tail.
Reversibility lens — One-way door or two-way door? A two-way door (easily reverted) should be walked through, not committee'd — if the design is cheap to undo, over-reviewing it wastes everyone's time and the finding is "just ship it and learn." A one-way door (data migration, public API, external contract) deserves the scrutiny the two-way door didn't. Failure it catches: mis-spent rigor — heavy process on reversible choices, light process on irreversible ones.
Failure lens — What has to be true for this to work, and what happens at each assumption's boundary? List the load-bearing assumptions, then push each to its edge: what at 10x load, at zero network, at a hostile input, at the second concurrent writer? Cross-check the prior postmortems from Step 0: does this design reintroduce a named past failure? Failure it catches: a design sound in the happy path and broken at every boundary.
Simplicity lens — Is there a materially smaller design that satisfies the stated goals? Name it concretely — "drop the queue and call synchronously; the goals never mention throughput" — not "simplify it," which is not a finding. YAGNI is a soundness argument, not a style note: speculative generality is unsound because it pays cost for a goal no one stated. Failure it catches: a design solving problems it doesn't have yet.
Scope lens — Are the non-goals temporal and justified, or is load-bearing scope being smuggled out the back? A good non-goal says "not now, because X, and here's the seam that lets us add it later." A bad non-goal quietly excludes the hard half of the actual problem so the design looks tractable. Read every non-goal and ask whether the design still solves the real problem without it. Failure it catches: a tractable design for a shrunken problem.