review-a-design

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

Updated Sep 7, 2026
One-click install
npx skills add https://github.com/jcafeitosa/anxionOS --skill review-a-design-jcafeitosa
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: review-a-design
Source: https://github.com/jcafeitosa/anxionOS/tree/main/.cursor/skills/review-a-design
Command: npx skills add https://github.com/jcafeitosa/anxionOS --skill review-a-design-jcafeitosa

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: Nine named lenses (problem, goal-derivation, alternatives, constraint, cost, reversibility, failure, simplicity, scope) test whether the design follows from its stated goals and constraints. - Context-aware reading: Reads the artifact end to end plus its parent proposals, superseded ADRs, and prior postmortems before critiquing, catching designs that contradict accepted decisions or repeat known failures. - Ranked, evidence-backed findings: Every finding carries a claim, a quoted evidence pointer, a severity (blocking/substantive/minor), and a resolution, then routes fixes to the right authoring skill. - Use Case: Before accepting a spec for a new sync subsystem, ask for a design review; the Skill reconstructs the argument, flags that the migration plan contradicts an accepted ADR, and returns a blocking finding with the exact quoted passage. ## 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 ranked findings with quoted evidence and severity instead of editing the document.

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 and constraints. This Skill performs only the soundness pass and routes fact-checking separately.

Can this Skill review code or a pull request diff?▼

No. Code review of diffs for bugs, style, or implementation quality is explicitly out of scope. The Skill reviews design artifacts such as proposals, specs, and ADRs, though it may read referenced source code to understand the design's context.

When should a design review be saved as a document?▼

Persist the review only when the user asks or when it is substantial enough to cite later, such as a blocking review of a proposal heading to accept or reject. Write it beside the artifact, link it from the artifact's open questions section, and mark it advisory.

What makes a design review finding actionable?▼

Each finding needs four parts: a one-sentence claim, quoted evidence from the artifact, a severity of blocking, substantive, or minor, and a concrete resolution or settling question. A finding without an evidence pointer is treated as opinion and dropped.