| name | dotnet-mcaf-ui-ux |
|---|---|
| version | 1.0.0 |
| category | Cross-Platform UI |
| description | Apply MCAF UI/UX guidance for design systems, accessibility, front-end technology selection, and design-to-development collaboration. Use when bootstrapping a UI project, choosing front-end stack, or tightening design and accessibility practices. |
| compatibility | Requires repository access when UI docs, component guidance, or design system rules live in the repo. |
- bootstrapping a UI project
- choosing front-end stack or design-system direction
- tightening accessibility or design-to-development collaboration
- produce a concrete project delta: code, docs, config, tests, CI, or review artifact
- reduce ambiguity through explicit planning, verification, and final validation skills
- leave reusable project context so future tasks are faster and safer
- pure backend or infrastructure work
- vague visual taste debates with no delivery consequence
- user outcomes, device targets, and accessibility needs
- design-system constraints and design handoff inputs
- current front-end stack and delivery constraints
- Read the nearest
AGENTS.mdand confirm scope and constraints. - Run this skill's
Workflowthrough theRalph Loopuntil outcomes are acceptable. - Return the
Required Result Formatwith concrete artifacts and verification evidence.
- Start from user outcomes and accessibility needs, not framework preference.
- Tie design choices to implementation and delivery constraints.
- Pull only the references that match the active UI decision.
- better UI/UX delivery guidance
- clearer front-end technology and accessibility decisions
- design-system-aware development notes
- accessibility is treated as a first-class requirement
- technology choices serve the product and team constraints
- design handoff guidance is actionable for engineers
Use the Ralph Loop for every task, including docs, architecture, testing, and tooling work.
- Brainstorm first (mandatory):
- analyze current state
- define the problem, target outcome, constraints, and risks
- generate options and think through trade-offs before committing
- capture the recommended direction and open questions
- Plan second (mandatory):
- write a detailed execution plan from the chosen direction
- list final validation skills to run at the end, with order and reason
- Execute one planned step and produce a concrete delta.
- Review the result and capture findings with actionable next fixes.
- Apply fixes in small batches and rerun the relevant checks or review steps.
- Update the plan after each iteration.
- Repeat until outcomes are acceptable or only explicit exceptions remain.
- If a dependency is missing, bootstrap it or return
status: not_applicablewith explicit reason and fallback path.
status:complete|clean|improved|configured|not_applicable|blockedplan: concise plan and current iteration stepactions_taken: concrete changes madevalidation_skills: final skills run, or skipped with reasonsverification: commands, checks, or review evidence summaryremaining: top unresolved items ornone
For setup-only requests with no execution, return status: configured and exact next commands.
- read
references/ui-ux.mdfirst - open
references/recommended-technologies.mdwhen the active question is front-end stack or tech selection
- "Choose the right frontend direction for this product."
- "Tighten accessibility and design handoff rules."
- "Document UI engineering guidance for this repo."