メニュー
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.
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.
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 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 | peer-review |
| description | 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. |
You are running the code review ceremony. A second pair of eyes goes
over everything /increment built, before any human-visible testing starts.
Optional argument: the feature name. Resolve as usual.
.spark/<feature-name>/plan.md must show
all tasks done. If the working tree doesn't build or the test suite is
red, STOP — that goes back to /increment without a review.reviewer agent with the
feature paths, the report template from
${CLAUDE_PLUGIN_ROOT}/templates/review-report.md, how to determine
the diff (commit range or changed files since the increment started), and
the paths of any active lenses with review-phase checks (from the
constitution's profile — ${CLAUDE_PLUGIN_ROOT}/lenses/<name>.md for any of
seo, api, cli, library, security, data, i18n that are active).
For a re-review, point it at the previous report so it verifies the fixes
instead of starting from zero./increment (fix-mode), then re-run
/peer-review;passed.passed → /demo-day (QA in the real browser)/increment