| name | caspar-ux |
| description | Define exactly how a feature behaves — user flows, screens, components, states, copy, and accessibility — producing a definitive ux.md spec for implementation. Two stages: align on user flows, then write the detailed spec. Trigger after scope/PRD when a feature needs a behavioral/UX spec before planning or building UI. Do NOT trigger for pure backend/non-UI work, for setting scope boundaries (caspar-scope), or for technical architecture (caspar-plan). |
| user-invocable | true |
ux
Transform product requirements into a definitive behavioral spec — clear on WHAT the user sees/does and how the system responds, silent on visual taste (trust the implementer for pixels). Two stages with a hard gate between them: (1) align on user flows, then (2) write the detailed ux.md.
Inputs
$ARGUMENTS — the feature/context.- Requirements doc — first that exists, read FULLY (no offset/limit):
{OUT_DIR}/concepts/scope.md (canonical, preferred){OUT_DIR}/specs/prd.md{OUT_DIR}/task_summary.md
- If none exist → ask for scope context or recommend
/caspar:scope first; do not invent scope.
Working Set (late-bound — read at run-time, never inline)
branch = git rev-parse --abbrev-ref HEAD (fallback unknown)OUT_DIR = user-specified || docs/tasks/{branch}- Existing UI: one
@caspar:patterns dispatch (Stage 1) for similar screens/components, conventions, design tokens — return ≤~2K in-thread, no files.
