Get started
From nothing to a first feature that has run the whole SPARK loop. Every command here comes from the products' own repositories.
Claude Code
The agent aSPARK runs inside as a plugin. claude must be callable from your terminal.
Git
The artifacts are versioned with your code — without a repository there is nothing to version.
Browser integration
Only for /demo-day: Claude in Chrome, a Playwright or a Chrome DevTools MCP server. Everything else runs fine without it.
The easy way is the built-in /plugin menu inside an interactive Claude Code session.
In an interactive session
In scripts and CI
The /plugin menu only works in an interactive session. For scripts, CI or a non-interactive shell, the CLI equivalents do exactly the same thing.
Local development install
To hack on aSPARK itself, point Claude Code at a local clone instead of the marketplace.
Each phase writes its artifact to .spark/<feature>/ and checks its gate at the end. You stay the decision maker — the loop stops at every gate.
Run /charter first. On an empty repo it asks a handful of hard product questions and ends by offering /story-time with the first slice named; on an existing codebase it reads the repo and writes down what it found, for you to correct once. Either way the team stops re-deriving what your project is on every feature. You can skip it, but /spark and /next-steps will point you here first.
No idea in hand? /next-steps surveys the project's current state and proposes the next feature.
What a finished run looks like: steamcore · highscore-system — spec, plan, review, QA and release of a real feature, ready to read.
All at once
/spark runs the same loop end to end, shows you the artifact before each transition and pauses at the gate. After heavy phases it points out that you can /clear and resume with /spark — the artifacts on disk are the state.
Core's gates are requests to a model. aspark-guard makes them checks that run outside it — from the same marketplace, one command, then a restart.
Requires Python 3.11+ and POSIX (macOS, Linux). It stays silent in any project without a .spark/ directory and fails open by design — a guard that blocks when unsure only teaches people to switch it off.
Check the rules against your own history
Replays all three gate rules read-only over the artifacts already on disk. On a project whose features ran cleanly it prints nothing but a count — every line it does print there is a false positive.
Where aspark-graph is present in the project, /sprint-plan, /peer-review and /demo-day use it to scope. Absent, nothing changes — no error, no warning.
The graph is not forwards-compatible across versions: rebuild after an upgrade. With uvx the latest published version always runs, so there is no separate update step.
A policy is not a package you install — it is a repository you mount. It sits as a submodule under .spark/policy and belongs to your organization.
Honest about the state: the format, schemas, packs and a resolve/validate CLI (v0.3.0) are in place — the /charter binding is not. The policy is readable, inheritable and auditable today, but no agent picks it up automatically yet.
A minimal policy.yaml
Where to go next
The product pages explain what sits behind each part — and the roadmap, what is still to come.