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

name, description

name	description
ms-frontend-design	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: hierarchy, navigation, grouping, choices, feedback, and error recovery. Read when changing structure or interaction behavior.
• Visual system: art direction, tokens, type, layout, motion, and interface copy. Read when choosing or changing appearance.
• Accessibility: measurable criteria and manual checks. Read for every implemented or changed user-facing surface.
• Site completeness: 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: 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.