review-a-design

Reviews design proposals, specs, and ADRs for soundness and emits ranked evidence-backed findings.

3.9k|256|Updated Jun 3, 2026
One-click install
npx skills add https://github.com/inkeep/open-knowledge --skill review-a-design
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: review-a-design
Source: https://github.com/inkeep/open-knowledge/tree/main/packages/server/assets/skills/packs/software-lifecycle/review-a-design
Command: npx skills add https://github.com/inkeep/open-knowledge --skill review-a-design

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Design documents can be complete and factually correct yet still solve the wrong problem, rest on strawman alternatives, or reintroduce past failures. This Skill performs a soundness review of proposals, specs, and decision records, producing ranked findings instead of edits.

Core Features & Use Cases

  • Soundness lenses: Runs nine named lenses (problem, goal-derivation, alternatives, constraint, cost, reversibility, failure, simplicity, scope) to test whether a design follows from its stated goals and constraints.
  • Evidence-backed findings: Emits findings ranked by severity (blocking, substantive, minor), each with a quoted evidence pointer, confidence level, and a concrete resolution or settling question.
  • Context-aware review: Reads the artifact end to end plus its parent proposals, superseded ADRs, and prior postmortems before critiquing, and hands off findings to the right authoring skill.
  • Use Case: Ask an agent to pressure-test a proposal in proposals/0003-feature.md; it reconstructs the design's argument, checks it against prior decisions and postmortems, and returns a ranked review without editing the document.

Quick Start

Ask the agent to review the design in proposals/0003-feature.md and tell you whether it is sound and what you should block on.

Frequently Asked Questions about review-a-design

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I review a design proposal for soundness?

Read the proposal end to end along with its parent decisions and related postmortems, reconstruct its argument in your own words, then run soundness lenses such as goal-derivation, alternatives, and failure. Emit findings ranked by severity with quoted evidence for each claim.

What is the difference between a soundness review and a correctness review?

A correctness review checks whether individual claims are true, while a soundness review asks whether the design should be built at all and follows from its stated goals. This Skill performs only the soundness pass and routes fact-checking separately.

Can this review specs and ADRs as well as proposals?

Yes, it reviews proposals, specs with a parent_proposal link, decision records with a supersedes chain, and even in-flight choices with no document yet. It reads inherited context like prior ADRs and postmortems before critiquing any of them.

Does the design review edit the document under review?

No, the review produces findings only and never edits the artifact unless explicitly asked. Findings are delivered in conversation by default, or persisted as a separate advisory review document linked from the original when requested.

When should I not use a design soundness review?

Do not use it for code review of a diff, fact-checking individual claims, or authoring new documents. Authoring routes to frame-a-proposal, write-a-spec, or record-a-decision, and completeness checks are a separate pass.