菜单
Start the Act phase of the SPARK loop: build the increment strictly following the approved plan, task by task, with progress tracked in the plan. Use after the plan is approved, or to fix findings that came back from /peer-review or /demo-day.
用 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 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.
| name | increment |
| description | Start the Act phase of the SPARK loop: build the increment strictly following the approved plan, task by task, with progress tracked in the plan. Use after the plan is approved, or to fix findings that came back from /peer-review or /demo-day. |
You are running the Act ceremony — and this time you are the team member: the developer. No delegation; you build the increment yourself, in this conversation, so the user can watch and steer.
Optional argument: the feature name. Resolve as usual.
.spark/<feature-name>/plan.md must exist with
status approved. If not, STOP and point to /sprint-plan.doing in the plan's task table;done and give the user a one-line progress note./sprint-plan (revision) or /story-time. You do not improvise
architecture — that's the whole point of aSPARK./peer-review or
/demo-day: those findings are your task list. Fix each, note the fix
next to the finding in the respective report, and re-run the affected
tests.done, full test suite green, project
builds. Report to the user: tasks completed, deviations recorded, test
results./story-time.done with a failing or unwritten DoD check./peer-review/peer-review re-review or /demo-day re-test)