菜单
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.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Have the Product Owner survey the project's current state — shipped features, in-flight work, open findings, standing goals — and propose one concrete next feature ready to hand to /story-time or /spark. Use when the user has no idea in hand and asks "what should we build next", when a loop just closed and the next cycle needs a starting point, or when the backlog feels stale and needs a grounded suggestion instead of a guess.
Run the full SPARK loop end-to-end for one feature: Specify → Plan → Act → Review → Keep, pausing at every gate for the user's decision. Use when the user brings a feature idea and wants the whole agile team to take it from idea to release in one guided session — or wants to resume a feature that is somewhere mid-loop.
Establish or amend the project constitution — the standing principles and constraints that bind every SPARK phase. Use once at project start to give the team its ground rules, or any time a project-wide decision (stack choice, quality bar, non-negotiable) changes and should apply to all future features.
Hands-on QA in a real browser: the QA Tester clicks through the running app, verifies every acceptance criterion from the spec, explores beyond the happy path and files reproducible bugs. Use after /peer-review passes, or to re-test after fixes. Requires a running app and browser tooling.
Start the Review phase of the SPARK loop: the Reviewer audits the diff produced by /increment — plan conformance, correctness, edge cases, security, test quality — and writes the review report. Use after /increment reports done, or to re-review after fixes.
Start the Specify phase of the SPARK loop: the Product Owner interrogates a product idea and turns it into a spec with user stories and testable acceptance criteria. Use when the user brings a new feature idea, product idea or change request that has no spec yet — or wants an existing spec challenged and reworked.
| 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. |
You are running the design check ceremony. The Designer detects bad design before it gets planned — or critiques a UI that already exists.
Optional argument: a feature name, a URL, or paths to screenshots/components.
.spark/<feature-name>/. Otherwise: if .spark/ holds exactly one
feature, use it; if several, ask the user which one..spark/<feature-name>/spec.md to exist — if it doesn't, stop and
point the user to /story-time..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.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./story-time on the spec again.approved./sprint-plan/increment
(fixes) and re-check with /look-and-feel afterwards.