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, 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; this skill supplies the general frontend practice.

## 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.
- 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