/look-and-feel — Specify (Designer)

You are running the design check ceremony. The Designer detects bad design before it gets planned — or critiques a UI that already exists.

Input

Optional argument: a feature name, a URL, or paths to screenshots/components.

Steps

1. Resolve the feature. If a feature name was given, use .spark/<feature-name>/. Otherwise: if .spark/ holds exactly one feature, use it; if several, ask the user which one.
2. Pick the mode.
   • Mode A (default): design-check the spec. Requires .spark/<feature-name>/spec.md to exist — if it doesn't, stop and point the user to /story-time.
   • Mode B: the user provided a URL, screenshots or component paths — critique the implemented UI. If a URL was given, capture evidence first (screenshots via the available browser tooling) so the agent judges what is actually rendered.
3. Resolve active lenses. The constitution is the single source of truth. Read the active lenses from .spark/constitution.md (its Project Profile section); pass the path of every active lens whose own frontmatter phases field includes design in step 4. To decide, read each active lens's file (${CLAUDE_PLUGIN_ROOT}/lenses/<name>.md); do not work from a list of lens names given here. If there's no constitution, do not apply lenses off a guess — only give a lightweight nudge: name the likely type in one line (e.g. "app-like web-app — a ux lens would apply") and point the user to /charter to record it. No lens is switched on without a confirmed constitution entry.
4. Delegate to the Designer. Invoke the designer agent with the mode, the feature paths, any evidence, and the paths of the design-relevant active lenses (${CLAUDE_PLUGIN_ROOT}/lenses/<name>.md). In Mode A it fills the Design Review section of the spec; in Mode B it returns a findings report.
5. Relay evidence requests. If the agent asks for missing evidence (screenshots, flows, viewports), get it from the user or the browser and re-invoke.
6. Present the findings by severity, each with location, violated rule and suggested fix. If the Designer raised scope questions, route them explicitly back to the PO: offer to run /story-time on the spec again.
7. Close the gate (Mode A). With the design review filled in, walk the SPEC GATE checklist with the user. Required design changes go into the spec (stories/ACs adjusted via the PO if needed). On the user's explicit approval, set the spec status to approved.

Rules

• Findings without location + rule + fix don't get presented — send them back to the agent.
• Blocker design findings block the SPEC GATE like any other open question.

Handoff

• Spec approved → /sprint-plan
• Mode B critique after implementation → findings feed /increment (fixes) and re-check with /look-and-feel afterwards.