# Design Critique > Review a proposed design, plan, architecture or RFC in one adversarial pass and produce ranked findings, each with a concrete failure scenario. Use when asked to review, critique, poke holes in or sanity-check a design before it is built, and before committing to anything expensive to reverse. - Skill: `chinthakat/design-critique` (Agent Skill) - Install (CLI): `npx skillmds@latest add chinthakat/design-critique` - Raw SKILL.md: https://api.skillmd.com/api/skills/chinthakat/design-critique/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: chinthakat (https://skillmd.com/u/chinthakat) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/chinthakat/design-critique --- # Design critique A one-pass adversarial review of a design that does not exist yet. The output is ranked findings, each of which names a way this fails in practice. This is not interrogation — there is no dialogue, and the author is not in the room. It is not code review either; the code has not been written, which is exactly why this is the cheapest moment to find the problem. ## 1. Restate the design before attacking it Write two or three sentences describing the design in your own words, and check them against the document. Do this first, every time. A large share of critique findings are misreadings — the reviewer attacked a design nobody proposed — and every one of those costs the author's trust and makes the real findings easier to dismiss. If you cannot restate it, that is the first finding: the design is not legible. ## 2. Attack the design, never the author "This won't work under concurrent writes" is a finding. "This wasn't thought through" is a mood. The second one is also unactionable, which is the practical objection to it. Every finding is a statement about the artifact. ## 3. The passes Work through these deliberately. Each finds a different class of problem, and skipping one is how a category gets missed entirely. | Pass | The question | |---|---| | **Correctness** | Does this do what the requirements said? Map each requirement to where it is handled. The unmapped one is the finding. | | **Failure** | What happens when each dependency is slow, down, or wrong? Slow is the hard one. | | **Concurrency** | Two users, two tabs, two retries, two workers. What happens when the same thing arrives twice? | | **Scale** | At 10x and at 100x. And at 0 and 1 — empty states and the very first record break more designs than volume does. | | **Security** | Who can see what? Take the `access-control-proof` identity matrix and walk it against this design. | | **Data** | What is the source of truth? What happens on a partial write? Can this lose data, and would anyone notice? | | **Operations** | How do you know it is broken? How do you debug one bad record? What does the rollback look like? | | **Migration** | How does the existing data get to the new shape, and what runs while it does? | | **Reversal** | If this turns out to be wrong in three months, what does undoing it cost? | | **Human** | What does a user do when this fails mid-way? What does support do when someone calls? | ## 4. Every finding names a concrete failure A principle is not a finding. Convert it into a scenario with actors and values: ``` Weak: This doesn't handle concurrency well. Strong: Two editors open record 88 on Monday morning. Both save. The second write overwrites the first because the update is a full document replace keyed on record id, with no version check. The first editor's 40 fields are gone and nothing logs it. ``` The strong version is arguable, testable and fixable. The weak one generates a defensive reply and no change. If you cannot construct the scenario, you have a suspicion. Say so explicitly and keep it in a separate list — suspicions are useful, but not if they are dressed as findings. ## 5. Rank by cost of being wrong Not by confidence, and not by how interesting the finding is. | Rank | Meaning | |---|---| | **Blocking** | Data loss, a security hole, or a one-way door that will be regretted. Do not build until resolved. | | **Significant** | Will cause incidents or rework, but is fixable afterwards at a known cost. | | **Improvement** | Better if changed, fine if not. | | **Taste** | You would have done it differently. Say so once, mark it as taste, and let it go. | Labelling taste as taste is what makes the blocking findings credible. A review that presents ten things at the same volume gets all ten discounted equally. ## 6. Hunt in the gaps, not in the text The findings that matter are usually about what the document does not mention: - The state nobody listed — the half-finished record, the deleted user who still owns rows, the tenant with zero of everything. - The second actor — a second user, a second device, a second tab, an admin doing it from the back office. - The unhappy exit — the user closes the laptop mid-flow. What is left behind? - The thing outside the boundary — a report, an export, a cache, a search index that also reads this data and was not mentioned. - The assumption stated as a fact — "the file will always be under 5MB". - **The number with no source.** Every figure in a design should be traceable to a measurement or labelled as an estimate. ## 7. Offer a direction, not a redesign For each blocking and significant finding, add a sentence on what would resolve it. Not a full alternative design — that hijacks the author's work and usually misses context you do not have. "Version check on update, reject on mismatch" is enough. If the fix needs three paragraphs, the finding is that the design needs a decision, and that is what to write. ## 8. Say what is good, briefly and specifically Not for morale — for signal. "The decision to keep submissions immutable is right and removes a whole class of problem" tells the author which parts are settled and stops a later revision quietly undoing them. Two or three lines. Specific, or leave it out. ## Output ```markdown ## What I understand this to be <2–3 sentences, in your own words> ## Blocking **B1 — ** Scenario: Direction: ## Significant **S1 — ...** ## Improvements - ... ## Taste (take or leave) - ... ## Suspicions — could not construct a scenario - ... ## Settled, and worth keeping - ... ``` ## Checklist - [ ] Design restated in your own words and checked before critiquing - [ ] Every pass run, including operations, migration and reversal - [ ] Every finding attached to a concrete scenario with actors and values - [ ] Suspicions separated from findings - [ ] Ranked by cost of being wrong; taste labelled as taste - [ ] Gaps hunted: missing states, second actors, unhappy exits, unmentioned readers - [ ] Numbers without a source flagged - [ ] A direction offered for each blocking and significant finding - [ ] What is settled and good stated specifically