Why aSPARK
What an AI coding assistant does not do, what aSPARK does instead — and what it explicitly refuses to be.
AI writes code faster than anyone checks it.
Generating has become cheap. What has become scarce is everything before and after: an idea somebody challenged, a plan that holds, a review somebody actually did, and proof that the thing really works.
Spec after the code
The idea goes straight into implementation. What was unclear surfaces in review — or in production. Nobody asked what “weekly” means for a user in another timezone.
Scope creep out of helpfulness
The assistant builds what wasn't ordered: a refactor here, an abstraction there. Without a plan as the fence, every task is open-ended.
Review as a rubber stamp
You review your own generated code, in the evening, in a diff viewer. Findings are recorded nowhere, fixes verified nowhere.
Green doesn't mean it works
Tests pass, but nobody opened the app and clicked. The bug where the chart never loads on mobile is in no test.
No trail
A week later nobody remembers why a decision went the way it did. The chat history is gone; the repo holds only the code.
Individually, small shortcuts. Together, a process that consists of nothing but building.
aSPARK puts the four missing phases back around the code — with gates you approve, and a trail that stays in the repository.
A team inside the plugin — not one more assistant.
| Category | Optimizes | It lacks |
|---|---|---|
| AI coding assistants Copilots, chat in the editor |
Throughput while writing code | Someone who challenges the idea, locks the plan, audits the diff and clicks through the app |
| Ticket tools & process suites | Planning, status, reporting | The rules where the code is written — inside the agent, at every transition |
| aSPARK | The whole delivery, not just the typing: Specify · Plan · Act · Review · Keep — every transition a gate, every gate your call | — a plugin, no service, no tracker |
Consequence: aSPARK never replaces Git, CI/CD or your issue tracker. It is Markdown in the plugin and Markdown in .spark/ — everything the team knows and decides sits in files you can read, diff and commit.
Five promises — each with the mechanism behind it.
Deliberately stated as checkable claims. The proof is not this page but the .spark/ folder of your own project.
Fewer wrong builds
The Product Owner challenges the idea and runs a clarify pass over boundaries, data, edge cases and UX states before a line of code exists.
No scope creep
The Engineering Manager cuts tasks, each mapped to a story. The Developer builds the plan — and nothing else.
Bugs somebody looked for
A Reviewer reads the diff with a staff-engineer eye, then a QA Tester clicks through the app in a real browser — acceptance criterion by acceptance criterion.
Traceability as a by-product
US-, AC- and NFR- IDs run from the spec through plan and review into the QA report. The trail is written while building, not reconstructed later.
Honest maturity
What was verified is marked passed. What could not be verified is marked partial or unproven — never silently green.
Non-goals keep aSPARK small
Not an SCM. Not a CI/CD engine. Not an issue tracker. Not a model of its own, no service, no account. And no obligation to extend — Core alone is complete.
Convinced? Then let's start.
Two commands in a claude session, a restart, /spark. No service, no account, no database — Core runs inside your repository. Everything is open on GitHub.