spectre-ux

name	spectre-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 (spectre-scope), or for technical architecture (spectre-plan).
user-invocable	true
disable-model-invocation	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 — explicit feature name/root or descendant requirements artifact.
• Requirements doc — first that exists, read FULLY (no offset/limit):
  1. {OUT_DIR}/concepts/scope.md (canonical, preferred)
  2. {OUT_DIR}/specs/prd.md
  3. {OUT_DIR}/task_summary.md
• If none exist → ask for scope context or recommend /spectre:scope first; do not invent scope.

Working Set (late-bound — read at run-time, never inline)