Decision records
What I considered, what I chose, and what I would do differently in a larger organization. Decided in public.
Decide in public
Decisions are written down before or while they are made, including the options I rejected. Readers can challenge them early.
Decide on data
Where data exists, it decides. Where it doesn't yet, the record says so and names the run that will produce it.
Which spec driven workflow?
Flow-Next goes first. Next to it run the four most widely adopted SDD frameworks, picked by GitHub stars, plus a baseline without any framework. Kiro is left out because it is tied to its own IDE and can't run in the same setup.
| Framework | Workflow | Strength | Watch out for | Role in this test |
|---|---|---|---|---|
| Flow-Next | Flow from idea, ticket or bug to a merged pull request; specs with numbered acceptance criteria, task state and receipts in the repo | End to end including landing; cross model review built in: the writer never reviews its own change | Young project that moves fast; an opinionated flow you have to buy into | Run 1: our pick, the benchmark the others are measured against |
| Superpowers | Brainstorm, then design only for architectural work, plan, test first per task, verify before done | Makes agents test and verify; design effort scales with the task | No spec for every change, no current system spec | Run 3: does discipline beat documents? |
| GitHub Spec Kit | Constitution, specify, clarify, plan, tasks, analyze, implement | Gates at every stage, full audit trail per feature | Around eight documents per feature, no single picture of the current system, heavy for small changes | Run 2: the reference for greenfield SDD |
| OpenSpec | Explore, propose, apply, archive; deltas merge into a living spec | Living spec of the whole system, reviewers read only what changed | One review point before apply, less governance trail | Change request test: how cheaply does a spec evolve? |
| BMAD Method | Product brief, PRD, architecture, epics and stories, then build per story with review | Models product roles and hand offs, scales to multi stakeholder work | Heavy for one person, versions with diverging guides | Run 4: do role based agent teams write better ERP specs? |
First assessment
| Workflow | End to end | Cross model review | Living system spec | Low ceremony | Fits solo work |
|---|---|---|---|---|---|
| Flow-Next our pick for run 1 | |||||
| Superpowers 291k stars | |||||
| GitHub Spec Kit 139k stars | |||||
| OpenSpec 70k stars | |||||
| BMAD Method 54k stars | |||||
| No framework baseline |
My reading of documentation and short trials, scale 1 to 5. Not a result. Cross model review can be added to any framework by hand; the column rates whether it is built in. Stars as of late September 2026 measure attention, not usage. The benchmark runs will replace these bars with measured numbers.
How other systems solve the same problems: prior art.
Tech stack at a glance
Accepted means decided. Proposed means a reasoned recommendation that gets confirmed before the milestone that needs it. Managed services over operations, open standards at every interface.
All records
Accepted, proposed or still open. Each one notes how the call would change at scale.