autosprint
Autosprint
One person architects; AI executes; engineers verify and ship. Autosprint standardizes that split. The operator (usually a founder or lead who plans across several projects) researches and approves a sprint plan, launches it, and walks away. A deterministic workflow implements it task by task with per-task commits and autonomous reviews. What comes back is a PR a human engineer can trust enough to verify, iterate, and merge — because it carries its plan, its evidence, its decisions, and a guide for testing it.
Terminology
| Term | Meaning | Unit of |
|---|---|---|
| Sprint | One autonomous delivery: one branch, one workflow run, one PR, one dashboard, one completion report | Handoff |
| Epic | A themed group of tasks inside a sprint; ends with an autonomous review that audits, repairs, and commits | Quality checkpoint |
| Task | One problem, one fresh-context agent, one commit, own spec file | Execution |
| Run | A single execution of the sprint workflow; interrupted sprints resume as a new run that skips completed work | Recovery |
| Ledger | status.jsonl — append-only event log every agent writes to; the single source of live truth |
State |
A sprint has no fixed size limit — the executor runs each task in its own fresh context, so a sprint can span many hours or days of autonomous work and land an entire feature, a large refactor, or a broad bug sweep. What grows with sprint size is the human verification burden at the end: when a plan gets enormous, advise the operator on how it could split into sequential sprints (and what each PR would deliver), then let them decide. Their team's review capacity is their call, not the skill's.
The four modes
Identify which mode the user is in and read only that reference. Users enter at any mode: a well-understood problem skips straight to plan; a written sprint goes straight to launch.