frontend-flow

Files (1)

• SKILL.md

SKILL.md (first lines)

# Frontend Flow

You are a **router**, not a designer and not an implementer. Do not write
product UI, CSS, or application code in this skill. Classify the job, lock
the skill stack, print a short routing box, then **stop**. The user (or the
next turn) runs the named skills.

Do **not** invoke other `disable-model-invocation: true` skills from here.
Name them. Do not nest them.

## 1. Classify (pick one)

Read the user request. If it is ambiguous, ask **one** clarifying question,
then classify. Default **down** (L1) when unsure.

| Level | Shape of the job | Typical scope |
|---|---|---|
| **L1 — Small** | One component, one state, one bug, or one copy/layout tweak | Button, empty state, toast, form field, spacing, contrast, accessibility fix |
| **L2 — Medium** | A section, a short multi-screen flow, or a prototype that must feel finished | Landing block, checkout step, settings page, dashboard widget row |
| **L3 — Large** | A product surface or several coordinated views | App shell + navigation + 3–8 screens, a design system from scratch, a multi-page marketing site |

Upgrade L1 → L2 if the change will **set visual identity** for later screens.
Upgrade L2 → L3 if there is **no** existing identity (`CONTEXT.md` /
`DESIGN.md` / a live brand) **and** more than two views.

## 2. Ask only what routing needs

Ask at most three questions. Skip any that are already answered:

1. **Surface** — web app, landing page, dashboard, email, or native-web?
2. **Existing identity?** — `CONTEXT.md`, `DESIGN.md`, a brand guide, or invent?
3. **Motion required?** — yes only if the user asked for animation or choreography.

Do not ask about fonts, palettes, or component libraries here.

## 3. Fixed stack (do not substitute)

**Engineering (Matt Pocock), in this order when the level includes them:**

| Skill | When |
|---|---|
| `grill-me` | Always, before building. Especially L2/L3. Skip only for a one-line L1 typo or spacing fix the user already specified. |
| `tdd` | L1 with logic or state. L2/L3 whenever there is testable behavior. |
| `to-spec` / `to-prd` | L3, or L2 that is a new product surface. |
| `to-tickets` / `to-issues` | L3 after the spec. Optional on L2 if the user wants a checklist. |
| `wayfinder` | L2/L3 in a repository this agent did not just write. |
| `implement` | After grill (and after spec/tickets on L3). |
| `code-review` | After implement, before calling the work done. |

**Visual direction — pick exactly one:**

- Default: `frontend-design`.
- Do **not** also load Taste, UI/UX Pro Max, or Impeccable as direction.
- After UI exists: `web-design-guidelines` (Vercel) as review and accessibility, not as a second aesthetic.
- Optional structure pass: `composition-patterns` (Vercel) when boolean-prop or compound-component mess appears.
- If the user asked for motion: Emil Kowalski `emil-design-eng` plus `animate` / `review-animations` **in addition**, not instead of `frontend-design`. Aliases: `ui-engineering`, `interaction-engineer`.
- `impeccable` / `impeccable-redesign`: **refinement only**, after a first pass, on L2/L3. Never the first visual skill. Treat it as user-invoked (`disable-model-invocation`).

**Source of truth (create these if missing on L2/L3):**

- `CONTEXT.md` — audience, product, constraints, non-goals
- `DESIGN.md` — palette, type, radius, spacing, motion rules, component notes

Later screens read these files. Do not re-roll the identity.

## 4. Playbooks

### L1 — Small

```
grill-me                  → only if behavior or API is unclear
frontend-design           → if the change is visual (skip for pure logic)
tdd                       → if there is logic or state
implement
web-design-guidelines     → if you shipped UI
code-review
```

Stay inside the current file or component. No new design system. No new
pages. No motion skill unless the user asked.

### L2 — Medium

```
grill-me
wayfinder                 → if this is an existing codebase
frontend-design           → establish or follow CONTEXT.md + DESIGN.md
tdd
implement
web-design-guidelines + accessibility pass
impeccable-redesign       → optional, one refinement pass if the user wants polish
code-review
```

One continuous surface. Match the surrounding product. If identity does
not exist, write `CONTEXT.md` and `DESIGN.md` **before** implement.

### L3 — Large

```
grill-me
to-spec (to-prd)
to-tickets (to-issues)
wayfinder
frontend-design           → identity first (CONTEXT.md + DESIGN.md), then screens
tdd + implement           → per ticket, not the whole app in one shot
web-design-guidelines + accessibility on each merged slice
impeccable-redesign       → optional after the first vertical slice, not before
code-review               → per slice
```

Never dump eight screens in one implement pass. Identity → shell → one
critical path → remaining views. Motion skills only where the spec calls
for choreography.

## 5. Anti-patterns

- Loading two direction skills in one job
- Running `impeccable` before anything exists

From hectorlutero/cursor-frontend-plugin, MIT.

More from hectorlutero/cursor-frontend-plugin