Frontend Stack

Frontend Stack router

Several design packs are installed side by side. Each is good alone and each assumes it is the only one in the room. This skill decides who leads in each phase of the work, so the agent loads one lead and at most two supporting skills at a time instead of five competing rulebooks.

frontend-design:frontend-design is the base. Load it first on every frontend task, whoever leads, and keep it loaded. It sits outside the lead/support count in step 7. If it is not in the session's skill list, say so once and go on.

1. Read the project first

Before picking anything, look for what the project already decided:

• PRODUCT.md / DESIGN.md at the repo root (Impeccable's context files)
• design-system/*/MASTER.md (UI UX Pro Max --persist output)
• docs/brand-guidelines.md, assets/design-tokens.* (UI UX Pro Max brand and design-system)
• an existing design system: tokens, tailwind.config.*, components/ui/, a component library in package.json
• a brand guide the user pointed at

If any of these exist, follow them by default (rules 1 and 2 of the precedence ladder). A personality, identity or "looks AI-made" complaint authorizes a replacement visual world within the complaint's scope, even with DESIGN.md.

Keep one source of truth. If two of these files exist and disagree (palette, fonts, spacing), ask the user which one wins before writing code. When the project has none, use the identity flow below for a new brand, or Impeccable document to capture an established world. DESIGN.md is the source of truth; do not also run --persist or generate docs/brand-guidelines.md unless the user asks, and if they do, keep the values identical to DESIGN.md.

2. Classify the request

Answer three questions before picking skills:

1. Job. Build something new; change something that exists (redesign, restyle, migrate to a library); review only (critique, audit, polish); one craft (motion, copy, color, type, layout, tokens); or assets (brand, logo, banners, slides).
2. Surface. Marketing (landing, portfolio, site); product (dashboard, chat, forms, settings, tables, flows); a single component; mobile web; native app.
3. Stack signals from step 1: a component library in package.json, shadcn (components.json, components/ui/), Tailwind, React Native/Expo, Swift.

Complaints about looks ("ugly", "generic", "looks AI-made", "slop", "cluttered") mean the job is change, not review: the user wants a new direction, not only a list of problems. An explicit review-only request stays read-only, even when it names an identity failure.

3. Work in phases

Bigger tasks run in phases, in this order. Load each phase's skills when the phase starts, not all up front. Skip a phase that the task does not need.

At the start, tell the user the phase plan with the skills of each phase, so they see the whole route even though only the first phase is loaded.

For a new landing with no brand, or a complaint about personality, identity, generic output or "looks AI-made", use the identity flow below first.

For any other complaint about looks, Diagnose and Direction run together: load impeccable:impeccable (critique), the Direction lead and ui-ux-pro-max:ui-ux-pro-max at the start, always, even when the request names no stack or style. A critique alone is a list of problems, not the new direction the user asked for. Research references before proposing directions (see identity-flow.md, step 2); reference-gallery.md seeds the board with inspected modern sites, grouped by the problem each one solves. UI UX Pro Max supplies UX and stack rules; category styles and presets are finishing material after the concept, never its source. When the project has a design system, use UI UX Pro Max for UX and stack rules only, not to replace the palette or fonts (rule 2 of the ladder).

Write what Diagnose and Direction decided (in DESIGN.md or the plan) before Build, so later phases do not need the earlier skills loaded.

When the product has no identity

Read references/identity-flow.md. It owns the full route: product context and naming/positioning → reference board → concept devices and Impeccable concept seed → 2-3 directions → prototype and user pick → brand → DESIGN.md and tokens → landing → screenshot finish gate.

The user picks the direction. Preserve their approved concept and praised or fixed visual choices. Presets finish a direction; they never generate it.

4. Pick the skills for the task

A request that mixes jobs ("redesign it and add animations") is several rows: run them as phases in the order of step 3.

5. Cases the table does not cover

New skills arrive with every upstream sync, and requests will not always match a row.

• No row fits: use the job and surface from step 2, give the lead to the domain owner (rule 5 of the ladder), then check the session's skill list for a skill whose description fits better.
• A named skill is not in the session's skill list: skip it and use the next row's lead or frontend-design:frontend-design. Never guess a name.
• Not a UI question: product strategy, positioning, what to build, specs, roadmap, metrics, backend architecture or running the business belong to the companion stack. If indie-dev-stack:indie-dev-stack is in the session's skill list, hand the request to it. Otherwise do what you can and tell the user once per session that the companion marketplace covers it: /plugin marketplace add JaimeJunr/claude-code-indie-dev-stack.
• A skill not listed here fits better: a row still wins unless the user names the other skill. Use it as support and tell the user this router has no row for it yet.

6. Precedence ladder

When two loaded skills disagree, the higher rule wins:

1. The user's explicit request and brand. "Use Inter", "purple is our brand", "keep it like Linear" beat every skill ban.
2. The project's existing system. DESIGN.md, tokens, the component library already in use. Extend it; do not swap libraries or mix systems. A complaint about personality, identity or "looks AI-made" authorizes replacing the visual world for what the complaint covers, even if DESIGN.md exists. Keep only the visual choices the user explicitly praised or fixed in that scope. Preserve product truth, working behavior, accessibility and the framework/library; leave unrelated surfaces alone.
3. Accessibility and correctness. Contrast, focus states, reduced motion, keyboard access, no layout shift. Impeccable audit is the referee.
4. Scope of the lead skill. A skill's own "not for X" line is binding. design-taste-frontend now also covers app screens, but the stack still leads product UI with frontend-design unless the user asks for Taste.
5. Domain owner. Motion questions go to Emil's skills, style/palette data to UI UX Pro Max, critique/audit/polish to Impeccable, aesthetic direction to frontend-design or taste.
6. The lead skill's taste defaults. frontend-design's anti-template rules outrank any other lead's taste defaults.

The rules that actually collide between packs, and how each is settled, are in references/conflicts.md. Read it when a supporting skill contradicts the lead.

7. Load budget

• Per phase: the base frontend-design, one lead and at most two supporting skills. Big skills (design-taste-frontend, ui-ux-pro-max, impeccable) are long; loading all of them at once burns context and produces averaged, generic output.
• Say in one line which skills each phase loaded, so the user can correct the routing early.
• Aesthetic presets (taste-classics: minimalist-ui, industrial-brutalist-ui, high-end-visual-design) never stack: at most one, as finishing material after the concept, or as the user's explicit choice.
• One marketing-page lead per task: taste:design-taste-frontend or hallmark:hallmark, never both. Hallmark's Floor binds only pages it leads.
• The brand, logo, banner and slides skills above overlap (ui-ux-pro-max:design and design-system also cover slides and branding). Load only the row's lead.
• Prefer the specific Emil skill over emil-design-eng:emil-design-eng as support: without a direct question the umbrella replies with a stock greeting.

8. Finish the same way every time

For anything user-facing, end with a review pass before calling it done:

1. Capture and open desktop + mobile screenshots with the session's available browser/screenshot tool. Compare the render with the reference board and chosen concept devices. Without tooling, report the missing visual evidence; do not claim the screenshot gate passed.
2. impeccable:impeccable audit (or delegate to the ui-reviewer agent). For new marketing pages, Build follows Impeccable's reference/new-work.md and hands captures + direction contract to impeccable-finish-reviewer (plugins/impeccable/agents/impeccable-finish-reviewer.md in this repo). Follow its recapture / rebuild / fix / ship disposition; use its documented fallback only when agents are unavailable. A page hallmark:hallmark or taste:design-taste-frontend led ends with that skill's own inspector and fix loop in place of that screenshot gate; still run audit for a11y.
3. If the change has motion, emil-design-eng:review-animations.
4. Fix the findings and recapture affected views. For personality/identity/ AI-look requests, a missing signature or a render interchangeable with a named competitor can block completion. Report evidence, verdict and gaps.