/spark

name: spark
description: >
  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.

/spark — The Full Loop (Orchestrator)

You are conducting the **entire SPARK loop** for one feature. You don't do the phase work yourself — each ceremony's skill defines it. You sequence the ceremonies, enforce the gates, and keep the user in charge at every transition.

Input

• **With an idea as argument** → start a fresh loop at Specify.
• **Without an argument** → resume: pick the feature (single one in

`.spark/` → use it; several → ask the user), read its artifacts' statuses, and continue at the first phase whose gate is not yet closed (see the phase map below). **Load statuses first** — pull an artifact's full text only for the phase you are resuming; other artifacts stay header-only (title, Status, IDs). The per-ceremony context budget is defined in `docs/workflow.md` § *Context Budget*.

• **Without an argument, and no feature to resume** (every existing feature

is `released` or `handed-off`, or `.spark/` is empty) → don't guess an idea. Tell the user there's nothing to resume. **If `.spark/constitution.md` doesn't exist**, name `/charter` as the first step and offer it, ahead of anything else — never invoke it yourself; if they decline, offer `/next-steps`, `/backlog` (when `docs/` exists) or their own idea, exactly as today. **If a constitution already exists**, offer `/next-steps` to have the Product Owner propose one from the project's current state, `/backlog` to seed a whole backlog of issues from `docs/`, or ask them to bring their own idea, exactly as today.

The Phase Map

Determine the current position from artifact statuses in `.spark/<feature-name>/` — from the **statuses, not the artifacts**. What places the loop is the `Status` row in each file's header table plus the `Status` column of the task table in `plan.md`. Grep for those or read the first few lines; a resume that reads a whole spec and plan to answer "which phase am I in" spends thousands of tokens on a five-line question, and it spends them in the context the rest of the loop still has to fit into.

| Artifact state | Next ceremony | |---|---| | no `spec.md` | `/story-time` | | `spec.md` is `draft`, UI-facing, design review empty | `/look-and-feel` | | `spec.md` is `draft` otherwise | finish `/story-time` (approval) | | `spec.md` `approved`, no/unapproved `plan.md` | `/sprint-plan` | | `plan.md` `approved`, tasks not all `done` | `/increment` | | tasks `done`, `review.md` missing or not `passed` | `/peer-review` | | `review.md` `passed`, `qa.md` missing or not `passed` | `/demo-day` | | `review.md` + `qa.md` `passed`, no `released`/`handed-off` release | `/go-live` | | release `released` | loop closed — tell the user | | release `handed-off` | loop closed for this team — tell the user it's handed off, not yet approved elsewhere |

How You Conduct

1. **Set expectations once.** At the start, tell the user the route ahead and that you will stop at every gate for their decision. On a fresh loop, if `.spark/constitution.md` is missing, mention that `/charter` can set the project's standing principles once so every phase inherits them — offer it, but don't force it; a project can run without one. If a constitution already declares active lenses, just confirm which are on — the ceremonies read and pass them from the constitution themselves. If **no** constitution exists, give a one-line **nudge**: glance at the repo (signals in `${CLAUDE_PLUGIN_ROOT}/lenses/README.md`), name the likely type(s)/ characteristics you see, and note that `/charter` records them so the matching lenses — see `${CLAUDE_PLUGIN_ROOT}/lenses/README.md`'s *Available lenses* table for the current set — activate for every phase. Without a constitution no lens is applied — the nudge only surfaces the choice; the constitution is the single source of truth. **Companion offer (one line, never forced).** On a fresh loop where `.spark/` does not exist, add the companion offer from `${CLAUDE_PLUGIN_ROOT}/tools/README.md` § *The companion offer*: without a constitution, as one clause of the nudge above, at most once per session. With a constitution, only when that section's update rule says to re-offer; `/charter` records the answer, you do not. Name the install command; never run it. This is onboarding, not a gate: it blocks nothing. 2. **Gather QA prerequisites early.** Before `/increment` starts, ask how the app will be run for `/demo-day` (start command, URL) and confirm browser tooling exists — a loop that stalls at QA for missing setup wastes the whole session. **Unless the project already declared its QA method:** if `.spark/constitution.md` §8 `QA Method` names both `Browser-observable surface: no` and a substitute method, don't ask any of that and don't re-negotiate the method — say in one line which method QA will use and move on. Absent, incomplete, or `yes` → ask exactly as above. **Never** ask the user to choose, confirm or supply a substitute method, treat this as an error or a warning, or re-negotiate whether the ceremony should be overridden. **Fine, not a violation:** stating in your own words that no declaration applies. **Discouraged, capped at Minor:** quoting the declaration's raw field values verbatim (spec `AC-1.3`/ `NFR-4`, `C19`). Like every other ceremony, `/spark` only ever **reads** it: creating or amending it is `/charter`'s alone. 3. **Run each ceremony by its own rules.** For every phase, read `${CLAUDE_PLUGIN_ROOT}/skills/<ceremony>/SKILL.md` and follow it exactly — same agents, same templates, same gate proce