# Frontend Design Workflow

Workflow for frontend features and visual/product design changes, present mockup...

- Repository: https://github.com/kirodotdev/KiroCrew (4711 stars)
- Category: Design
- License: Apache-2.0
- Last updated: 2026-11-01
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add kirodotdev/KiroCrew --skill frontend-design-workflow -g -a claude-code -y`
Codex: `npx skills add kirodotdev/KiroCrew --skill frontend-design-workflow -g -a codex -y`
Cursor: `npx skills add kirodotdev/KiroCrew --skill frontend-design-workflow -g -a cursor -y`
Gemini CLI: `npx skills add kirodotdev/KiroCrew --skill frontend-design-workflow -g -a gemini-cli -y`

## Description

Workflow for frontend features and visual/product design changes, present mockup options before code, build on the project's design system, capture the right evidence (screenshots vs video), run a new-user usability review. Use when building or changing UI, styling, layout or animation.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# Frontend & Design Workflow

A disciplined workflow for frontend features, visual changes, and product
design changes. The core idea: **design decisions happen in cheap mockups
before expensive code**, and **evidence matches the nature of the change**.

## Phase 1, Mockups before code

Never jump straight to implementation when a change involves design
decisions, even when one design seems obvious.

**Skip mockups only when there is nothing to design**: the change is
mechanical and fully specified, fixing a typo, changing a value the user
prescribed exactly ("make this #FF0000", "bump the font to 14px"), or
deleting something. If the request leaves *any* visual choice open
(layout, spacing, color selection, interaction), mockups are required.

1. Render **2, 3 distinct design options** as mockups for the user to choose
   from. For small components, inline widgets work well when the chat
   surface renders them; otherwise, and for full pages or complex
   layouts, write a self-contained HTML file and share the path.
2. Make each option genuinely different (layout, density, interaction
   model), not three shades of the same idea.
3. Build mockups with the target project's real design tokens / theme
   variables when they exist, so the options preview accurately.
4. Recommend one option with reasoning, but let the user decide.
5. **The chosen mockup IS the visual spec.** Record which option was picked.

## Phase 2, Implementation

The rest: https://github.com/kirodotdev/KiroCrew/blob/HEAD/src/kiro_crew/builtin_skills/frontend-design-workflow/SKILL.md