Review a design — is it sound, not just complete

The platform open-knowledge skill still governs every markdown operation here (reads via exec, writes via write/edit, links as plain relative markdown, MCP owns in-scope .md); this skill layers design-review craft on top of it.

Three reviews are not the same review, and only one is this skill's job.

• Completeness review asks: is every section filled in? (Are Drawbacks and Alternatives non-empty?)
• Correctness review asks: are the individual claims true? (Does the benchmark really say 40ms? Is that API deprecated?)
• Soundness review asks: should this be built at all, and is this the design that follows from the stated goals and constraints?

You are doing the third. A proposal can be complete and factually correct and still be the wrong design — solving a symptom, chosen before its goals, engaging only strawman alternatives. Completeness and correctness are cheap to check and someone else's pass. Say this to the user up front if there's any ambiguity about what kind of review they want, then do soundness.

You produce findings, not edits. The author decides what to change. Never rewrite the artifact under review unless explicitly asked.

Step 0: Identify the artifact and read it — and what it inherits

HARD GATE: never review a design you have not read end to end, and never review it in isolation from the decisions it inherits. A review of the first half is worse than no review — it spends the author's trust on partial understanding.