just-design
Just Design
Turn a confirmed scope into an agreed UI/UX design for customer or internal interfaces. Always write a design document when invoked; add mockups when they help settle decisions. End with the document. Technical architecture, task slicing, and production implementation belong to later work.
1. Establish the boundary
Read the supplied scope in full, or find docs/scope-*.md and ask which one when unclear. If missing, unconfirmed, or carrying open questions, stop and ask the user to finish scope first.
Keep its R and AC IDs, constraints, and exclusions. If a design decision requires changing requirements, explain the conflict, preserve the design as a draft, and ask the user to update scope before continuing dependent work. Leave the scope file unchanged.
Use the requested output path or docs/design-<feature-name>.md, matching the scope's feature name. For other filenames, derive a short hyphenated name from the content. Check the target early. Update when requested, otherwise ask before replacing an existing document. If no repo exists, tell the user and use the current directory.
2. Inspect the experience
Read repo instructions and inspect affected journeys, screens, components, design tokens, and existing design guidance. View the current interface when available. Distinguish observed behavior from code evidence. Cite file paths and component or symbol names. Resolve factual questions through inspection before asking the user.
Determine whether the scope changes anything a person sees or does, including staff tools, messages, and interaction behavior. If none does, write a short document linking the scope, with Status: Not needed, the evidence for that conclusion, and any limitations. Finish there. Uncertain impact is an open question, not grounds to skip.