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.11.0 — 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). What's still open: the situational-lenses layer is 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.