Your first loop: start with /charter, not with the feature
Install, project profile, first feature: what to do in your first hour with aSPARK — and which decision at each gate is genuinely yours.
Since v0.11.0, aSPARK has one clear starting point. Running /spark or /next-steps on a project without a constitution used to leave you between the two — each behaved as if the other had already set things up. Today both point to /charter first, and /charter knows what to do whether the repository is empty or has been growing for two years.
Install: two commands
In a running claude session:
/plugin marketplace add a-lottes/aSPARK
/plugin install aspark@aspark
Then restart Claude Code — plugins only activate after a restart. A /plugin afterwards lists aspark as installed and enabled. There is no service, no account and no database: aSPARK is Markdown that works inside your repository.
Step 1: /charter, once per project
/charter writes the constitution: the standing rules every phase of every feature inherits. The ceremony behaves differently depending on what it finds.
On an empty repository it asks a short set of hard product questions. Who is this for? What do those people do today without it? What is the smallest version that would already help? How will you know it is working? Which stack, which hard constraints? It ends with a proposed constitution and a proposed first slice — both offered for your go, nothing starts unasked.
On a project that already has code it reads what is there instead: the README, an existing CLAUDE.md, existing specs. Out of that comes a bounded project picture — who it is for, the stack, how to run it, conventions, known pain points — which you correct once. After that, the Product Owner and Engineering Manager no longer re-derive the system on every feature.
Three entries deserve particular attention, because they shape the rest of the loop:
- Project type and characteristics. These decide which lenses are active. A public
websitegets SEO checks, anapigets error-envelope and versioning checks, a project that handles payments gets the security lens through every phase. Important: without a constitution, no lens is active. The constitution is the only place a lens is switched on. - Quality bar. Whatever sits in §4 no spec has to repeat. If there is no test framework and none should appear, write that down — then nobody builds one.
- QA method. If your project has no surface a browser can drive, declare the substitute method here. Otherwise every feature asks again.
Step 2: the first feature
Either phase by phase, or in one go:
/spark A filter bar above the todo list with All, Active, Done …
/spark runs Specify, Plan, Act, Review and Keep, stopping at every gate. You see the artifact and decide. That is not ceremony for its own sake — it is the point: the agents draft, check and recommend; approval is yours.
What is actually on the table at each gate:
| Gate | Your question |
|---|---|
| Spec | Is this the right feature, and are the criteria testable? |
| Plan | Does the approach hold? Rejecting is still cheap here; after this, code exists. |
| Review | Findings understood: fix now, or knowingly accept? |
| QA | Was every acceptance criterion actually verified? |
| Release | Does this ship? Nothing happens without your explicit yes. |
After heavy phases, /spark offers you a /clear and a fresh start. Take it. The artifacts on disk are the state; a fresh context resumes the loop exactly where it stood, without carrying everything the last phase read.
Step 3: extend, optionally
Core is complete on its own. Two extensions hook into the loop if you install them:
/plugin install aspark-guard@aspark
aspark-guard moves the gates out of the prompt into a check that runs outside the model, and keeps a hash ledger of every write under .spark/. aspark-graph (pip install aspark-graph) scopes plan, review and QA to the files that are actually involved. Without either, the loop behaves exactly as described — no error, no warning.
What you have after the first hour
A feature that has passed five gates, and a .spark/ folder you can read, diff and commit: a spec with stories and acceptance criteria, a plan with tasks, a review with findings, a QA report with every criterion checked, and a release note with what was learned.
Plus a constitution you never have to explain again.
What such a run looks like in practice is in the demo video on the home page: 47 minutes of a real session, cut to 100 seconds.