Frontend Direction

---
name: frontend-direction
description: Choose a distinctive, coherent visual direction and source-backed components before building a new frontend, page, or substantial UI redesign. Use for frontend implementation and requests to make an interface less generic; keep small fixes within the existing design.
license: MIT
metadata:
  author: Oleg Koval
  tags: frontend, design, components, art-direction
---

# Frontend direction

For Pi, Codex, Claude Code and Hermes, using the existing frontend stack. Use the host's available file, shell, browsing and image-inspection tools; no provider-specific tool names or plugins are required. Resolve bundled reference paths relative to this skill folder. Browsing and browser inspection improve source selection and visual verification; their absence must be reported, not disguised as verification.

Make a deliberate visual choice before writing interface code. Deliver a recognizable composition that serves this product's users, with components that belong together. Distinctiveness can come from typography, imagery, spatial hierarchy, content or interaction; it does not require animation or new dependencies.

## Match the effort to the task

For a new page or substantial redesign, use the workflow below. For a small fix, reuse the established components and tokens and verify the affected state. Do not turn a spacing correction into a redesign or browse libraries on every turn. If another design skill supplies an approved direction, use it and perform the component selection here without repeating discovery.

Read the relevant application instructions, stack, existing components and visual conventions. Inspect the current screen when available. Infer the audience, primary action, content density and constraints from the task. Ask only when a missing decision materially changes the result; otherwise state the assumption and proceed within the user's authorization.

## Choose the direction before the components

For an open-ended brief, consider two or three genuinely different compositions and choose the strongest fit. A color swap is not a different direction. A buyer comparing evidence may need an inspection workspace; a photographer may need an image-led editorial sequence. Avoid defaulting every product to a centered hero followed by identical cards.

Briefly state the choice and why it helps the primary task. Do not require approval unless the user requested a design checkpoint or the choice would change their scope or brand. Respect supplied designs and existing systems.

Define the visual anchors: layout and hierarchy, typography roles, palette, density, image treatment, and motion purpose. Reuse tokens where possible. Choose one or two signature treatments for emphasis, such as an annotated comparison rail or an editorial image sequence. Keep frequent controls familiar. Treat these as a default attention budget, not a prohibition on expressive briefs.

## Select a coherent component set

Read [references/sources.md](references/sources.md) when external references would improve the result. The catalog is a starting point, not a required dependency list. Existing project components and a small custom implementation are valid choices.

Start with at most three relevant candidates. Expand only if none fits. Judge task fit, visual coherence, stack compatibility, accessibility, dependency cost and reuse terms. Do not rank novelty above usability or invent numeric scores that imply measurement.

Inspect the exact official component page and available source before copying or installing. Record the URL, intended adaptation, dependencies, and known license or paid-access boundary. Unknown terms mean do not copy that source until clarified; use existing primitives or an original implementation instead. A screenshot or a social recommendation does not verify source availability or accessibility. Inspect registry payloads and install commands before execution.

Prefer one primary component family per surface. Borrow an isolated interaction from another source only when it can share the same typography, spacing, radius, color and motion conventions. Never add a framework merely to use a decorative component. If browsing fails, label references unverified, use local primitives, and continue without claiming live checks.

Before substantial implementation, leave a compact decision record in the task's existing plan, or in the response if no plan exists:

| UI role | Chosen component or pattern | Source or local path | Why it fits | Adaptation and cost |
| --- | --- | --- | --- | --- |
| Primary comparison | Aligned comparison rows | Existing table primitive | Makes differences scanable | Shared column widths; no dependency |

Record the chosen direction and the most relevant rejected alternative with its reason. Reuse this decision on later turns; revisit only when evidence or requirements change. Do not create a new document for every small edit.

## Build the composition, then inspect it

Implement one representative section with realistic content before repeating it across the page. Establish shared tokens, responsive behavior and meaningful hierarchy there. Keep the product's actual states, including loading, empty, error, long text and unknown data. Decorative charts and invented statistics are not a substitute for content.

Use motion to explain a transition or provide feedback. Preserve keyboard focus, semantics and immediate response; support reduced motion and interruption. Never hide essential content behind hover or animation.

Inspect the rendered screen at desktop and narrow mobile sizes when browser tools are available. Check the primary action, text hierarchy, contrast, keyboard use, overflow, long content and relevant failure states. Compare the result with the chosen direction: does its composition still express it, or did it collapse into repeated generic cards? Is the signature treatment useful and proportionate?

Make one focused correction pass for observed issues. Continue only for a specific unresolved defect, rather than redesigning indefinitely. Run the project's relevant checks. If visual inspection is unavailable, report that limit explicitly and distinguish code checks from visual acceptance.

Report the direction, components and sources selected, dependencies added, and what was actually verified. This skill does not authorize deployment, publication or purchases.