---
name: plan-review-design
description: Use when reviewing the UX/UI portion of a plan before implementation — rate each design dimension 0-10, explain what would make it a 10, and patch the plan to get there.
---
## Triggers
- design plan review
- review ux plan
- check design decisions
- design critique
- review the design
- plan design review
- review ui plan
- visual design review (planning, not live audit)
# Plan Review — Design mode
## Overview
This review runs *between* CEO review and engineering review. By
this point the scope is set; this pass shapes the *user experience*
before architecture is locked. For live-site visual audits of
already-shipped UI, use a different skill — this one operates on
the plan, not on rendered pixels.
**Don't re-litigate scope.** If a design problem reveals a scope
issue, escalate it back to CEO review rather than silently shrinking
or growing the plan.
## Six dimensions to score (0–10)
For each, one sentence on what makes it a 10, then the score.
1. **First five seconds** — when a brand-new user lands, do they
immediately understand what this is and what to do? "Hero says
X" / "primary CTA is Y" / "what they see first is Z."
2. **Information hierarchy** — does the page/screen order things
from most important to least? Can a user accomplish the primary
goal without scrolling, hovering, or hunting?
3. **Native interaction patterns** — does the design lean on
patterns the user already knows (web/iOS/Android conventions),
or invent novel patterns that need explaining?
4. **State coverage** — every interactive surface needs explicit
loading, empty, error, partial-success, and success states. A
plan that only describes the happy path is a 0 here regardless
of how pretty the happy path is.
5. **Accessibility floor** — keyboard navigation, focus states,
colour contrast (WCAG AA minimum), screen-reader labels,
captions for video, alt text for image. Not optional.
6. **Brand fit** — does this look and read like the same product
it claims to belong to? Match the existing styleguide
(`knowledge/system/styleguide.md`), don't invent a new vibe per
feature.
Below 7 on any dimension ➜ patch the plan before approval.
## What you must add to the plan
If the plan is missing any of these, write them in directly:
- **Wireframe sketch** — ASCII or component-level breakdown of the
primary screens. Doesn't need to be pretty; needs to be specific
enough that an eng reviewer can map it to components.
- **Copy block** — exact text for hero, primary CTA, error states,
empty state. "TBD copy" is not acceptable; if you genuinely don't
know, write your best guess and mark it `[needs-copy-review]`.
- **State table** — for each interactive surface, list states
(default / loading / empty / error / success) with what the user
sees in each.
- **Responsive breakpoints** — what happens below 640 px wide?
Below 380 px? Cite specifics, not "responsive."
- **Style references** — link to the existing components or
patterns in the codebase or styleguide that this should mirror,
so the eng review knows what already exists.
## How to use
1. Read the plan (path / text / active goal).
2. Pull `knowledge_search(scope="system")` for `styleguide.md`,
`identity.md`, and any brand context.
3. Walk the six dimensions.
4. Patch the plan in place OR return a structured diff with
escalations.
When called from `plan_autoplan`, return the JSON schema the tool
expects. When called interactively, narrative + revised plan is
fine.
## Hard rules
- Don't accept "we'll figure out copy later" — write it now or
flag it.
- Don't accept loading/empty/error states marked TODO — design
them or punt with a placeholder spec.
- Don't introduce new visual primitives without naming the
existing ones we considered and rejected.
- Don't move ahead with accessibility scores below 7 — they
compound into legal and reputation risk.
## What this skill does NOT do
- Pick architecture (eng review's job).
- Re-open scope (CEO review's job — escalate).
- Audit a live, deployed site (different skill).
- Write code or generate visual assets.
## Verify
- The deliverable for this phase exists as a concrete artifact (doc, ticket, board, repo) and its location is shared, not described
- Each commitment has an owner name, a due date, and a definition-of-done that someone other than the author could check
- Risks are listed with likelihood/impact and a named mitigation, not as a generic 'risks: TBD' bullet
- Dependencies on other teams/vendors/agents are explicit; an ack from each dependency is recorded or marked 'pending'
- Success criteria for the next phase are numeric or otherwise objectively testable
- A rollback / kill-switch / 'we will stop if X' criterion is written down before work starts