stack/skills/ms-frontend-design/SKILL.md

---
name: ms-frontend-design
description: Design, implement, and review frontend interfaces with intentional visual identity, concrete usability and accessibility rules, complete interaction states, and site-completeness checks. Use for new websites, application UI, redesigns, and visual or interaction repairs.
---

# Frontend design

Build interfaces that help the intended audience complete real tasks. Give
visual choices a reason grounded in the subject, content, and product. Treat
usability, accessibility, functioning interactions, and site completeness as
part of design delivery.

## Scope and rule strength

- **Requirement (MUST):** an acceptance condition when its stated scope
  applies. Record an unmet condition; do not silently downgrade it.
- **Heuristic (SHOULD):** a contextual default. Depart when the brief,
  existing system, or observed user behavior supports a better choice.
- **Preference (MAY):** an aesthetic option subordinate to the brief.

These instructions do not grant tools, access, publication authority, or
permission to expand the user's task. Explicit user scope governs. Where it
excludes a normally required item, record the exclusion and its consequence.

Choose the mode from the request and existing project:

- **New site or complete redesign:** own the affected routes, shared shell,
  interaction states, and applicable site-completeness requirements.
- **Existing product extension:** reuse its components, tokens, vocabulary,
  and navigation; complete the new flows and their integration points.
- **Targeted repair or component:** verify the changed surface and affected
  behavior. Report unrelated site gaps without rebuilding the site.
- **Prototype or design-only deliverable:** demonstrate the relevant routes
  and states; identify simulated behavior and missing facts. Do not claim
  working delivery, production readiness, or legal compliance from a mockup.

## Operating loop

1. **Ground.** Inspect the brief, real content, existing interface, and
   project conventions. Identify audience, primary task, interface type,
   constraints, and mode. Ask only when missing information materially changes
   the design or is needed for a truthful functional deliverable; proceed
   with independent work while it is unresolved. Never invent client history,
   business identity, contact details, endorsements, or data practices.
2. **Plan.** For substantial work, make a compact route/state inventory and
   design plan: hierarchy, semantic tokens, responsive behavior, and relevant
   acceptance checks. Reuse the current system before adding tokens. Scale
   planning down for a small repair; it need not create a document.
3. **Implement.** Build the actual navigation and interactions with realistic
   content. Include applicable loading, empty, error, success, focus, selected,
   and disabled states. Complete required support pages and shared content
   within scope; a footer label or decorative banner does not fulfill them.
4. **Inspect and exercise.** Review the rendered result at representative
   widths and layout transitions. Exercise the primary task, keyboard path,
   and failure/recovery behavior. Fix observed failures and recheck affected
   behavior. Source inspection alone does not establish visual correctness.
5. **Deliver evidence.** State the result, consequential decisions, checks
   performed, and remaining limitations. Use `pass`, `fail`, `not applicable`
   (with reason), or `not verified` (with missing evidence). Do not describe
   an untested or incomplete requirement as complete.

## Read the relevant references

Keep these files with the skill. Read only the portions needed for the task;
for a complete site, all five references apply.

- [Design principles](references/design-principles.md): hierarchy, navigation,
  grouping, choices, feedback, and error recovery. Read when changing structure
  or interaction behavior.
- [Visual system](references/visual-system.md): art direction, tokens, type,
  layout, motion, and interface copy. Read when choosing or changing appearance.
- [Accessibility](references/accessibility.md): measurable criteria and manual
  checks. Read for every implemented or changed user-facing surface.
- [Site completeness](references/site-completeness.md): required pages, contact
  methods, privacy, consent, routing, footer, and dynamic copyright. Read for
  site-level work and changes to any of those features or data integrations.
- [Verification](references/verification.md): evidence, completion gates, and
  scenario checks. Read before declaring implementation or review complete.

## Essential design rules

- MUST keep control meanings, labels, visual hierarchy, and actual behavior
  consistent. Prefer semantic native elements and established interactions.
- MUST preserve accessible operation and relevant states as layouts change.
  Default accessibility target: WCAG 2.2 AA; the reference checklist is a
  practical subset, not proof of full conformance.
- MUST implement a recovery path for failure and unknown routes within scope.
  Preserve recoverable user input; never fake a successful submission.
- MUST complete the applicable site inventory for new public sites: 404,
  About, Contact with real methods, privacy notice, shared footer and dynamic
  copyright, plus consent controls and other policy pages where applicable.
- SHOULD express identity through content, typography, composition, imagery,
  and a coherent token system. Preserve familiar control behavior while
  making the visual treatment appropriate to the subject.
- SHOULD make every structural device communicate a relationship. Use
  numbering for real sequences, grouping for related content, and emphasis
  for meaningful priority. Keep decorative effects from competing with tasks.
- MAY concentrate expressive treatment in a memorable focal area when the
  brief benefits from it. A dashboard need not have a hero. No palette,
  typeface, radius, or layout style is universally required or forbidden.

## Portable execution

The workflow requires capabilities, not a particular agent, framework, CLI,
browser product, persistent memory, or companion skill. Use the project's
available file, render, interaction, and validation tools. Equivalent tools
are acceptable when they verify the same behavior.

When rendering, network inspection, delivery testing, or another needed
capability is unavailable, continue useful authorized work and identify the
specific checks as `not verified`. A missing tool is not a passing check.
Use local guidance to work offline; consult the cited primary sources when
an applicable standard, legal requirement, or uncertain detail needs current
verification. Do not assume every harness automatically discovers SKILL.md;
the instructions also work when explicitly supplied with their references.