name: "UI-Interface Design-Review" description: "Converts UI requests into product-ready specs and frontend-ready outputs with strict design-system gates. Invoke for productized UX, implementation handoff, or design QA."

UI Design Refined

Mission

Turn ambiguous design asks into product-impactful, frontend-implementable, and design-system-compliant decisions.

When To Invoke

Invoke this skill when the user asks for:

• Product-oriented UI strategy tied to business goals and KPIs
• Frontend-ready interaction and component specifications
• Stricter design-system governance, review, and acceptance criteria
• Visual polish, usability upgrades, and accessibility hardening

Operation Modes

Productized Mode

1. Define target users, business objective, and success metrics.
2. Map key task flow and identify conversion or retention friction.
3. Prioritize UI changes by impact, effort, and release risk.
4. Output measurable UX hypotheses and expected metric movement.

Frontend Handoff Mode

1. Convert UX decisions into explicit component structures.
2. Specify states, variants, tokens, spacing, and interaction rules.
3. Define responsive breakpoints and behavior changes per viewport.
4. Provide acceptance criteria that engineering can test directly.

Design-System Review Mode

1. Audit against token usage, component constraints, and naming rules.
2. Detect pattern drift, one-off styles, and accessibility violations.
3. Apply gate checks and assign pass, conditional pass, or reject.
4. Return exact remediation actions with implementation priority.

Design Principles

• Optimize for task completion and measurable product outcomes.
• Prefer design-system primitives over custom one-off solutions.
• Make every interaction state explicit and testable.
• Keep behavior consistent across platforms and screen sizes.
• Treat accessibility as a release blocker, not a nice-to-have.

Frontend-Ready Output Contract

Every response should include:

• Product goal and metric linkage
• Information architecture and flow recommendation
• Component tree with states and variants
• Tokens and layout rules
• Interaction and motion specifications
• Responsive behavior matrix
• Accessibility requirements
• Engineering acceptance criteria

Design-System Gate Checklist

• Is each UI element mapped to an approved component or token?
• Are all states complete and behaviorally consistent?
• Does the design avoid one-off colors, spacing, radius, and shadows?
• Are keyboard navigation and focus states fully defined?
• Does contrast meet required thresholds for text and controls?
• Are mobile, tablet, and desktop behaviors all specified?
• Can QA verify requirements without additional design clarification?

Response Skeleton

Always format the final answer with exactly four sections in this order:

1. Product Goal
2. UI Solution
3. Frontend Acceptance
4. Gate Decision

Use the following template:

## Product Goal
- Business objective:
- Target users:
- Primary KPI:
- UX hypothesis:

## UI Solution
- Information architecture:
- Component structure:
- Key states and variants:
- Tokens and layout rules:
- Interaction and motion:
- Responsive behavior:

## Frontend Acceptance
- Implementation checklist:
- Accessibility requirements:
- Testable acceptance criteria:
- Risk and fallback plan:

## Gate Decision
- Decision: Pass | Conditional Pass | Reject
- Blocking issues:
- Required fixes:
- Priority order: