spark git:20260829.47f6040A

Immutable. This exact content is served forever at /api/v1/blob/0bee43547a1b65f4.

---
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).
- **Without an argument, and no feature to resume** (every existing feature
  is `released`, or `.spark/` is empty) → don't guess an idea. Tell the user
  there's nothing to resume and offer `/next-steps` to have the Product Owner
  propose one from the project's current state, or ask them to bring their
  own idea.

## 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 (`seo`, `ux`, `api`, `cli`, `library`, `security`, `i18n`, `data`)
   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.
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,
   and say nothing about the declaration. 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 procedure. You add nothing and
   skip nothing.
4. **Stop at every gate.** Present the phase's artifact and result, then get
   the user's explicit decision: approve and continue, iterate this phase,
   or stop here (a paused loop resumes later via `/spark`). Never roll
   through a gate on momentum — an approval for the spec is not an approval
   for the plan.
5. **Offer the clean handoff at heavy gates.** The artifacts *are* the
   state, which makes every closed gate a safe place to start again with an
   empty context. After the user approves a gate that followed heavy work —
   Act (`/increment`), QA (`/demo-day`), and every fix round — tell them in
   one line: the conversation is still carrying everything that phase read,
   edited and logged, and none of it is needed for the next phase. They can
   `/clear` and continue with `/spark`, which resumes from the artifacts
   exactly where they stand. Before you offer it, make sure every status on
   disk is current — the resume reads those and nothing else. Offer it;
   never do it for them, and never present it as damage control. It's how
   the loop is built.
6. **Handle the feedback loops.** Review or QA findings route back through
   `/increment` (fix-mode) and then re-run the phase that found them. Count
   the rounds: after **3 failed rounds of the same phase**, stop and lay the
   situation before the user — the plan or the spec is probably wrong, and
   grinding harder won't fix that. Offer `/sprint-plan` (revision) or
   `/story-time`.
7. **Keep the narrative.** At each transition, give a one-paragraph
   state-of-the-loop: what just closed, what's next, what's still ahead.
   The user should never wonder where in the loop they are.
8. **Close the loop.** After `/go-live`, summarize the whole journey:
   idea → what shipped, rounds needed, learnings kept. Then offer
   `/story-time` for the next idea, or `/next-steps` if the user wants the
   Product Owner to propose one instead of bringing their own.

## Rules

- Every gate needs the user's explicit decision **in this conversation** —
  including the final go for publishing in `/go-live`. If the user asked to
  "run it all without stopping", still honor the two hard stops: plan
  approval and the publish go.
- All ceremony rules apply unchanged; on conflict, the ceremony's own
  SKILL.md wins for its phase.
- If the session ends mid-loop, the artifacts *are* the state — any later
  `/spark` resumes from them. Leave statuses accurate at all times.