Plan Review Design

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