菜单
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.
用 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.
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.
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 | demo-day |
| description | 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. |
You are running the QA ceremony. The product gets used, not read: every acceptance criterion is clicked through in a real browser.
Argument: the app URL (and optionally the feature name). No URL → ask the user for it, and how to start the app if it isn't running.
.spark/<feature-name>/review.md must be passed. If not, stop and
point to /peer-review. (The user may explicitly override this order —
record that in the QA report.)qa-tester agent with the app
URL, the feature paths, the agreed viewports, any credentials/test data
the user provided, the report template from
${CLAUDE_PLUGIN_ROOT}/templates/qa-report.md, and the paths of any active
lenses with browser-observable checks (from the constitution's profile —
${CLAUDE_PLUGIN_ROOT}/lenses/ — ux.md, seo.md, security.md, i18n.md)./increment (fix-mode), then
/demo-day again. Re-tests cover the fixed bugs and their
surrounding flows.passed.passed while a Must-story AC is unverified.passed → /go-live (release it)/increment