aSPARK Core
The deterministic delivery process: five phases, five gates, a team of specialized roles — and a ticket trail versioned alongside the code.
The SPARK loop: five phases, five gates.
Every feature travels through five phases — and may only advance when the previous gate is green. Each phase reads the prior phase's artifact and refuses to start if the gate isn't met.
One person plus aSPARK works like a whole team. Each role is a subagent — stateless, with its own mindset, standards and allowed tools.
Two ceremonies belong to no single role: /spark runs the whole loop end to end — stopping at every gate, resuming after. /next-steps proposes the next feature from the project's current state, for when the question is "what now?".
Every decision stays in the project
Each feature gets a working directory — a transparent, reviewable ticket trail, versioned with the code.
Stable IDs across the whole cycle
Requirements carry stable IDs — US-, AC-, NFR- — from spec to release. The plan cites which AC a task covers; review traces each Must-AC to code; QA verifies it under the same ID. Nothing silently falls out of the chain.
Situational lenses switch on by project type — seo · ux · api · cli · library · security · i18n · data · accessibility — giving the existing team extra checks, only where they apply.
Optional graph link: where aspark-graph is present in the project, /sprint-plan, /peer-review and /demo-day use it silently to scope — which files a task touches, what a review reads first, which stories QA should probe hardest. Absent, nothing changes. A graph answer is a map, never a gate verdict; the ceremonies never build the graph themselves.
Honest status: aSPARK Core is in daily production use at v0.14.1 — the full SPARK loop (10 skills, 7 agents, 6 templates), PR-mode delivery (handed-off), and a Handoff block that compresses every report to a fixed, ≤12-line address. Two rounds of right-sizing came after that: reports that survive their second pass — a re-review or re-test updates findings, verdict and summary in place instead of stacking another round section on top of the last (v0.7.0) — and a QA method declared once in the constitution, so a project with no browser-observable surface stops renegotiating the same override on every feature (v0.8.0) — plus a ninth lens, accessibility (v0.9.0). Since then, every lens a project switches on is dispatched from one registry, so it runs in every phase it claims (v0.10.0), and /charter became the start: a kickoff interview on an empty repo, a discovery pass on an existing one, and one shared Project Context the Product Owner and Engineering Manager cite instead of re-deriving it (v0.11.0). Most recently, /story-time can start straight from a GitHub issue, and /go-live can post one status update back to it on request (v0.12.0). New and experimental: campaigns — one measurable goal you approve, a budget and stop rules, run in iterations; the first kind migrates code in reversible slices, each checked by a fresh Parity Verifier (v0.13.0). And a recorded search of the repo's own trails for gate evasions found one, too few to add defensive rules yet (v0.13.1). Since v0.14.0 a campaign starts with one command: /campaign writes a draft from your goal and leaves approving and running it to you. What's still open: the situational-lenses layer and ticket import are dogfooded but not yet proven live on someone else's project, and the QA declaration has run on this repository and on steamcore, an ESP32 console built from scratch with aSPARK. Core's gates are also prompt-enforced, not code-enforced — aSPARK-guard is the companion plugin that closes exactly that gap. Every claim here is demonstrated live, never just asserted — the full evidence trail lives in docs/status.md.
Each product has one responsibility and stable interfaces. A weakness in one must never require changes in another.
Does this fit your delivery process?
Start with Core on a pilot project. The workflow, knowledge graph and policy packs are all open on GitHub.