Review A Design
Reviews whether a design is SOUND, solving the right problem, derived from its stated...
Install
npx skills add inkeep/open-knowledge --skill review-a-design -g -a claude-code -y- Repository
- inkeep/open-knowledge4.8k
- Category
- Design
- Updated
- 4d ago
- License
- GPL-3.0
- Context cost
- Mediumabout 3,000 tokens
- Runs scripts
- No, instructions only
What it does
Reviews whether a design is SOUND, solving the right problem, derived from its stated goals and constraints, and emits ranked, evidence-backed findings, not edits. Read when asked to 'review this design', 'is this design sound', 'pressure-test this proposal', 'do a design review', 'does this solve the right problem', 'poke holes in this spec', 'should we build this', or to critique a proposal / spec / ADR / architecture or product decision. Do NOT read when the user wants to AUTHOR one of these, routing a new proposal is frame-a-proposal, a spec is write-a-spec, a decision record is record-a-decision, a postmortem is write-a-postmortem. Do NOT read for code review of a diff, or to fact-check individual claims (that is a correctness pass, a different job).
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.
