Atomic Tasks and Atomic Commits
In spec-driven development, an atomic task is a small unit of implementation that can be verified in isolation, described with a four-field prompt (role, task, constraints, and success criteria). Independent tasks are executed in parallel waves, and each task closes with an atomic commit: one commit per task, which preserves the requirement → design → task → commit chain.
The tasks phase transforms the complexity of a large change into a series of small changes with clear boundaries. The complexity does not disappear, but it becomes a manageable sequence.
Anatomy of an atomic task
A well-defined task typically touches between one and three files; if it needs more, it can probably be broken down. At its core is a structured four-field prompt:
| Field | What it defines |
|---|---|
| Role | The point of view the agent adopts. |
| Task | The specific scope of what needs to be done. |
| Constraints | The boundaries of that task (see AGENTS.md). |
| Success criteria | What allows the task to be checked without rereading all the code. |
The four fields are not bureaucracy: they are what makes the task verifiable in isolation, because its result can be evaluated without having completed the others.
Parallel Task Waves
Tasks are not necessarily sequential. Those that do not depend on one another are grouped into the same wave and run in parallel, each one by a subagent with a clean context; the waves themselves run in sequence. The model leverages agents' ability to work in parallel without the context of one task contaminating that of another, and it is the orchestrator-workers pattern described in Anthropic's guide on building effective agents.
The order of the waves is dictated by the dependencies in the design: first, whatever creates the structures that the others depend on; next, whatever uses them; and finally, whatever integrates them. A task that waits on another task in its own wave is a sign that the decomposition did not respect the dependencies.
Atomic commits and the traceability chain
Each task produces an independent commit, with three consequences: granular reversibility (a defective task can be reverted without affecting the others), effective bisection (it is possible to pinpoint exactly which task introduced a defect), and traceability. The latter is the chain that runs through the entire method: each commit is linked to a task, each task to a design, and each design to a set of requirements. That requirement → design → task → commit chain is what proves useful when facing a regulator (see Traceability and human oversight).
There is a limit. If the prompt describing a task is longer than the code it will produce, the decomposition has gone too far. The right size is one that allows the agent to work with full context and the person to review the result at a glance, in minutes rather than hours.
Common mistake
Commits that mix several tasks. They lose granular reversibility and traceability, and make bisection useless. At the other extreme is excessive decomposition: if the prompt is longer than the code it produces, the cost outweighs the benefit. The right size is one that can be taken in at a glance and fits in a single commit linked to a task, a design, and a set of requirements.
Resources
📊 Guía didáctica SDD [SDD Teaching Guide, in Spanish]Resources · Scrum Manager
🏦 SDD en equipos ágiles [SDD in Agile Teams, in Spanish]Skill Arena · Scrum Manager
References
- Anthropic. (2024). "Building effective agents."
- GitHub. (2026). Spec Kit (project documentation).
See also
Want to advance in agility? You can search for calls for courses and exams, or go at your own pace by becoming a member of the Agile Club. This membership includes exclusive resources, e-learning classrooms, and access to Skill Arena: a space to practice and measure your agile skills at your own pace.