Vertical axis
Rigor — how much ceremony
Lean, Standard or Strict. Dials the depth of analysis, how many lenses the review uses, and which checks run — by how much is at stake.
Methodology and rigor
Renaming a button label and rewriting the billing engine don’t deserve the same ceremony. And a team that speaks in sprints and story points shouldn’t have to translate everything just to adopt a tool. Spaccy has two controls for this, and they’re independent.
Vertical axis
Lean, Standard or Strict. Dials the depth of analysis, how many lenses the review uses, and which checks run — by how much is at stake.
Horizontal axis
Standard, Agile or Enterprise. Swaps the vocabulary, the artifacts, the grouping and the screen the cockpit opens to — to match the process your team already runs.
They’re orthogonal: an agile team can go up to Strict on a payment feature without ever stopping talking in stories and sprints. Choosing one doesn’t lock in the other.
The vertical axis
The same set of commands, with more or less depth. Each tier contains the one before it — going up never swaps one check for another, it only adds.
CRUD, tweaks, low-risk fixes
The essentials and nothing more: intent, acceptance criteria and the structural review. The deep-analysis sections, the risk matrix and the cross-check are left out — not because they don’t matter, but because renaming a label doesn’t justify their cost.
Day-to-day work
The default balance: a complete proposal, a spec with invariants and traceability, a review across three independent lenses — structural, edge-case hunter, and verification-gap detector. It’s the tier most features are born at.
Payments, sensitive data, what can’t fail
Everything from Standard plus the adversarial lens: the reviewer assumes the code is wrong and tries to prove it. For every acceptance criterion, it hunts for the path that violates it. It also brings in the threat, privacy and full requirement-to-test traceability sections.


The horizontal axis
Methodology isn’t a color theme: it changes the command you specify with, the name of every artifact, what gets grouped by what, and the screen the cockpit opens to. All of it is configuration — not one line of the product changes.
| Aspect | Standard | Agile | Enterprise |
|---|---|---|---|
| You specify with | /proposal | /story | /proposal |
| The unit is called | Feature · Phase | Story · Increment | RFC · Work item |
| Thematic grouping | Theme (off) | Epic | Capability |
| Time-based grouping | Milestone | Sprint (2 weeks) | Program Increment |
| Backlog prioritized by | — (off) | MoSCoW | WSJF |
| Estimation | — (off) | Story points (Fibonacci) | Effort (t-shirt sizes) |
| The cockpit opens to | List | Kanban + velocity | Traceability + compliance |
| Rigor that comes with it | Standard | Lean | Strict |
Every methodology is a config file that inherits from another and switches roles on or off — building your own costs one file, not a fork. The rigor on the last row is just the starting point: the two axes stay independent.
What changes for the team
On an agile team the panel opens in kanban, with velocity and story points; on an enterprise team, in a traceability and compliance matrix. It isn’t a visual theme: it’s the unit of work, the grouping and the metric changing together. Nobody has to mentally translate “phase” into “sprint” during the meeting.
What the team already calls a story stays a story — in the artifacts, in the cockpit and in the commands. Adopting Spaccy stops costing a language migration, which is where most process tools go to die: the team falls back to the old vocabulary in two weeks and the tool becomes theater.
The standup comes ready out of the repository — yesterday, today and blockers read from git and the history, not from anyone’s memory. A technical uncertainty turns into a time-boxed experiment that reports the finding and produces no spec at all. The ritual stops depending on who remembered to prepare it.
/standup/spike
The rigor tier has three configuration layers: the product default, the team convention — versioned in git, reviewed like any other file — and your personal preference, which stays on your machine and never goes into the repository. Disagreeing with the team doesn’t require convincing the team.
What changes for the AI agents
Dosing isn’t a polite request to the model — it’s the instruction it receives changing size. The agent doesn’t decide its own rigor.
There isn’t an agile version and an enterprise version of every command to keep in sync — there’s one, with each section tagged by the tier it belongs to. Raising or lowering rigor switches parts of the same instruction on and off. That’s what avoids the usual fate of this kind of system: three variants silently drifting until none of them is right.
Strict contains Standard, which contains Lean. Raising rigor only adds — it never swaps one check for another. You can raise the tier on a critical feature knowing nothing that was already checked stopped being checked.
The specification — whether it comes from a formal proposal or a user story — emits the same intent contract. The rest of the path (spec, implement, review) reads the contract and doesn’t know which origin it came from. That’s why methodology is a config file, not a fork of the product.
Six engines are immune to the rigor tier: the ones that rotate the history, reorganize modules, prepare the environment, create a session branch and remove obsolete code. Those are exactly the ones that write over existing work — for them, “lighter” would mean “without the check that prevents loss.” Rigor dials ceremony, never safety.
Both axes ship configured at Standard — if you change nothing, that's what runs. Request early access and tune it when the work calls for it.