feat(skills): six new ms-* skills
ms-archify (evidence-based architectural mapping), ms-sdlc, ms-proactive-agent, ms-goal, ms-grill-me, ms-frontend-design.
This commit is contained in:
@@ -0,0 +1,115 @@
|
||||
---
|
||||
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.
|
||||
Reference in New Issue
Block a user