Look And Feel

---
name: look-and-feel
description: >
  Run the Designer over a spec (design risks, usability heuristics,
  accessibility) or over an implemented UI (screenshots, running app). Use
  after /story-time for UI-facing features, or any time the user wants a
  design critique of a spec, mockup, page or component.
---

# /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.