frontend-design

Files (1)

• SKILL.md

SKILL.md (first lines)

# Frontend Design

## Communication Style

Be extremely concise. Sacrifice grammar for the sake of concision.
No em-dashes or en-dashes. Ever.

Use this skill only when the Linear/GitHub issue, prototype brief, specs, ADRs,
repo instructions, or code clearly put UI/frontend work in scope.

When the target has a domain-specific UI skill or design constitution, load it
before making visual or interaction decisions. That source supplies the local
language and outranks this skill only where it states its own rule; this skill
supplies the general frontend practice, which still holds wherever that source
is silent.

## Accepted mockup

A screen the brief names an accepted mockup for is built from that mockup, not
from judgment, and checked against each of its frames at that frame's width, as
`agents/implementer.md` states (spec `#delivery-mockup`). The practice below
fills only what no mockup draws and never overrides one.

## Scope

- Respect existing design systems, component libraries, tokens, and patterns.
- Build the actual requested interface, not a marketing placeholder.
- Keep layouts responsive, readable, and free of text overlap.
- Avoid unnecessary secondary labels and descriptions. Let the layout do the
  explaining: grouping, order, alignment, and spacing show what each part is
  and how the parts relate. Add a caption, helper line, or subtitle only where
  the layout cannot show it.
- For every user-facing string (label, hint, empty state, toast,
  confirmation, button text), load `clean-copy`: cut what should not exist
  before phrasing what stays.
- Use target repo assets and UI libraries before inventing new ones.
- Use icons for common tool actions when the project has an icon library.
- Validate through the target repo's normal checks and browser/screenshot
  evidence when the issue or repo convention calls for it.

## Boundaries

- Do not redesign unrelated surfaces.
- Do not introduce a new design system unless the issue explicitly asks.
- Do not hide incomplete behavior behind decorative UI.
- Stop for shaping/operator clarification when visual requirements,
  brand constraints, or acceptance evidence are ambiguous.
- Where no mockup draws the screen, treat design guidance as agent judgment.
  Do not turn it into product code, lint gates, or new enforcement machinery
  unless the issue explicitly asks.

From varelaseb/octo-lite, Apache-2.0.

More from varelaseb/octo-lite