/charter

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

/charter — The Project Constitution

You are setting the **standing context** for the whole SPARK loop. The constitution lives at `.spark/constitution.md` and is read by every agent before phase work — so decisions that hold across all features are made once here, not re-argued in every `/story-time`.

Input

Optional argument: a principle, constraint, or "set up our ground rules". No argument → offer to create the constitution from scratch or amend the existing one.

Steps

1. **Delegate to the Facilitator.** Pick the model first: if `.spark/constitution.md` §11 names a model for `facilitator`, pass exactly that as the agent call's `model`; if it names none, or there is no constitution or no §11, pass no model, so the agent's own default (`sonnet`) applies. Then invoke the `facilitator` agent with the path `.spark/constitution.md`, the template from `${CLAUDE_PLUGIN_ROOT}/templates/constitution.md`, and the user's input verbatim. Say whether this is a first draft or an amendment if you already know; the agent will otherwise detect it from the file's presence. The Facilitator has no shell — for §9 Project Context, always gather a read-only git summary yourself (`git log --oneline -20`, further back on a young project; if the repo has no commits at all, hand over that it is empty rather than nothing) and hand it over with the rest, the same pattern `/next-steps` step 1 uses for the loop-state brief. Do this on every first draft, not only ones with source files or a manifest — a greenfield repo can still have real commits worth grounding §9 in — **and do it again on any amendment that touches §9** (adding it where absent, or correcting an existing entry): the Facilitator's own git history is no fresher on an amendment than on a first draft, so skipping it there would recreate the same false-`absent` risk one call site over. The Facilitator reads `README.md`, `CLAUDE.md` and `.spark/` specs itself via its own Read tool. 2. **Relay, don't guess.** The agent grounds a draft in the codebase but cannot talk to the user. When it returns questions — the team's priorities, a deliberate quality bar, a contradiction only the user can resolve — put them to the user (AskUserQuestion where the choices are enumerable), then re-invoke the agent with the answers. 3. **Present the result.** Show the user the drafted constitution, separating what the agent **inferred from the project** from what still needs their decision, plus any contradiction it flagged. Keep it short — a constitution nobody reads is dead weight. Surface the **detected type(s), characteristics and proposed active lenses** (e.g. `seo`, `ux`, `security`) as their own decision, with the evidence the agent found — this is what makes later phases situational (an SEO lens only runs on a `website`, a `security` lens only when the project handles auth or PII), so confirm it consciously with the user rather than letting it ride. Also surface the **active-lens load** — if 4+ lenses come out active, flag the elevated load so the user sees each phase will carry several lenses (no cap, just visibility). Surface the **QA method** (§8) as its own explicit decision too, with the evidence the agent found — whether this project has a browser-observable surface, and if not, which method the QA phase performs instead. Never let it ride on the profile or the lens state: a project with no `website` and no `web-app` is *evidence* for the question, never the answer to it, so a mis-typed profile can never suppress QA on its own. Leaving it undeclared is a valid answer and the default — QA then behaves exactly as it does today. `/charter` is the only ceremony that may create or amend this declaration. Surface the **Project Context** (§9) as its own decision too, in this same round — never a separate one: show the product brief and, where the repo has code, the system picture, each entry marked `inferred from <file:line>` / `asked` / `confirmed by user` / `not stated` / `not found` so the user can confirm or correct in one pass alongside the profile and QA method. On a **first draft**, or on an amendment where §10 is absent or the update rule in `${CLAUDE_PLUGIN_ROOT}/tools/README.md` § *The companion offer* applies, read `version` from `${CLAUDE_PLUGIN_ROOT}/.claude-plugin/plugin.json` for the Facilitator, make that one offer in this same round (AskUserQuestion; never a separate round) and record the answer in §10. Never run an install. 4. **Iterate.** Fold the user's edits back in via the agent until they're satisfied. On an amendment, confirm the *Amendments* log records the change and its reason. 5. **Confirm.** Remind the user the constitution now binds every phase — the PO scopes within it, the EM plans within it, the Reviewer enforces it. If the kickoff interview named a first slice, offer `/story-time <first slice>` and invoke it only on the user's explicit go — never automatically.

Rules

• The constitution holds **principles and constraints**, never per-feature

requirements — those belong in a spec. If the user brings a feature idea here, note it and point them to `/story-time`.

• The **active lenses** are the user's decision, like every other entry.

Detection proposes them from the repo; it never switches one on silently. A lens the team won't act on comes back off — dead weight erodes trust in the rest of the constitution.

• Keep every entry falsifiable and true. Delete aspirational lines the project

doesn't actually