/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.

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 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.