NEW Browse AI tools across categories — updated daily. See what's new →

UI Interface Design Review

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.

AuthorDuanjyy
Version1.0.0
LicenseMIT
Token count~959
UpdatedJun 5, 2026

Install

Quick install

via npx skills · works with 57+ agents
npx skills add https://github.com/Duanjyy/UI-Interface-Design-Review
Or pick agent:
npx skills add Duanjyy/UI-Interface-Design-Review --agent claude-code
npx skills add Duanjyy/UI-Interface-Design-Review --agent cursor
npx skills add Duanjyy/UI-Interface-Design-Review --agent codex
npx skills add Duanjyy/UI-Interface-Design-Review --agent opencode
npx skills add Duanjyy/UI-Interface-Design-Review --agent github-copilot
npx skills add Duanjyy/UI-Interface-Design-Review --agent windsurf
More install options

Shorthand — useful for multi-skill repos:

npx skills add Duanjyy/UI-Interface-Design-Review

Manual — clone the repo and drop the folder into your agent's skills directory:

git clone https://github.com/Duanjyy/UI-Interface-Design-Review.git
cp -r UI-Interface-Design-Review ~/.claude/skills/
How to use: Once installed, ask your agent to "use the UI-Interface Design-Review skill" or describe what you want (e.g. "Converts UI requests into product-ready specs and frontend-ready outputs with st"). Requires Node.js 18+.

UI-Interface Design-Review

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.

---
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:

---

Source: https://github.com/Duanjyy/UI-Interface-Design-Review
Author: Duanjyy
Discovered via: skillsdirectory.com
Genre: design

SKILL.md source

---
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-Interface Design-Review

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.

---
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:

```markdown
## 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:
```


---

**Source**: https://github.com/Duanjyy/UI-Interface-Design-Review
**Author**: Duanjyy
**Discovered via**: skillsdirectory.com
**Genre**: design