agentsclimarketplace
Sign in

Look and feel

Skill a-lottes/aSPARK/skills/look-and-feel

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.From its SKILL.md

Install
npx -y skills add a-lottes/aSPARK --skill look-and-feel

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 24 stars24 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

3.1 KB, as published. Nobody here has run it

/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); the design-relevant ones are ux, seo (content structure) and i18n (text expansion, RTL) — pass those paths in step 4. 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.

Keep looking

Skills are one crate of 627,801. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.