ui-spec
UI Specification
Turn a settled product idea into the user experience another agent can implement without inventing the design. This skill answers: what should the user experience? It does not choose implementation architecture or write code.
Use this after the product has been sharpened, normally with /grill-with-docs in a working directory. If essential product facts remain unknown, ask only the focused questions that affect the critical journey. For a small, clear request, state reasonable assumptions and continue.
Process
-
Inspect the available product requirements, project vocabulary, brand material, and existing interface. When modifying a product, preserve established patterns unless they fail the user goal. Identify the target users, their context, their goals, and their highest-value journey.
-
Challenge unsupported UI requests before treating them as requirements. For each proposed navigation area, card, chart, icon, badge, AI surface, or decorative treatment, name the user goal, decision, or action it serves. Remove or replace elements that have no answer. Derive the interface from user → goal → decision → action → feedback, not from a familiar dashboard template.
-
Define the experience at the detail the project needs. Start with the critical journey, then cover secondary journeys only when they materially affect it. Specify navigation only when it solves a navigation problem. Scale the document: a small feature may need one journey and a few screens; a larger product may need information architecture and reusable patterns.
-
Write
docs/ux-spec.md. Createdocs/if it does not exist. Clearly mark assumptions and open decisions so/tech-specdoes not mistake them for approved requirements. Do not write code, component file paths, APIs, database design, or technical architecture. -
Review the document against the checks below. Present the decisions and any questions that still need human approval.