# Review A Design

Reviews whether a design is SOUND, solving the right problem, derived from its stated...

- Repository: https://github.com/inkeep/open-knowledge (4756 stars)
- Category: Design
- License: GPL-3.0
- Last updated: 2026-10-31
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add inkeep/open-knowledge --skill review-a-design -g -a claude-code -y`
Codex: `npx skills add inkeep/open-knowledge --skill review-a-design -g -a codex -y`
Cursor: `npx skills add inkeep/open-knowledge --skill review-a-design -g -a cursor -y`
Gemini CLI: `npx skills add inkeep/open-knowledge --skill review-a-design -g -a gemini-cli -y`

## Description

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).

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# 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.

The rest: https://github.com/inkeep/open-knowledge/blob/HEAD/packages/server/assets/skills/packs/software-lifecycle/review-a-design/SKILL.md