Use when refining an architecture or design document based on new learnings, before a rewrite. Use when you have an existing doc and related docs to cross-check against. Use when you need systematic section-by-section validation of decisions.
/plugin marketplace add alizain/wizard-wheezes/plugin install utils@eightzerothreeThis skill inherits all available tools. When active, it can use any tool Claude has access to.
Design review separates validation from rewriting. Go section-by-section through a design doc, cross-check against new learnings, record changes with rationale, then rewrite in a fresh session.
Core principle: Changes document first, rewrite second. Never edit inline.
Don't use: Writing from scratch (use brainstorming), minor edits, obvious changes.
# [Design Name] v[N+1]: Changes
> After full review, create fresh v[N+1] incorporating all changes.
## Changes
For each section:
Questions to ask:
### [N]. [Short Description]
**Section:** [Section name]
**Change:** [What's changing]
**Rationale:** [Why]
---
| Principle | Meaning |
|---|---|
| Main body vs Appendix | "What we're doing" vs "paths we rejected" |
| No mixed content | Remove sections with undiscussed details mixed in |
| Feature sections own data | Each feature owns its endpoints/models, no central lists |
| No timelines | Architecture = what, not when |
Do NOT rewrite in same session. Start fresh with:
| Mistake | Fix |
|---|---|
| Inline editing | Always use changes document |
| Skipping sections | Review every section |
| No rationale | Always include "why" |
| Same-session rewrite | Fresh session for rewrite |
| Keeping auto-generated details | Validate each or remove |