The planner: how a coding task gets a plan
The planner is the first AI role on a task: it reads the repository, asks clarifying questions in batches and writes a plan that you approve before any of up to 8 subtasks exist.
What the role does
In an agentic pipeline, this role turns a short request into a concrete approach. It explores the code, works out which files change and why, and records the steps. No code is written at this stage.
How DevFlow runs it
Clicking Start planning creates a git worktree on a new branch. The run first looks for an AGENTS.md file, or a legacy CLAUDE.md, and stops if neither exists. The repo scanner proposes one when the repository is onboarded.
This role has the full tool set, because exploration needs it. When something is ambiguous, it stops and asks.
Questions arrive in batches, you answer inline, and the run continues. This loop can repeat before a proposal comes out.
After the plan
The result lands in plan review. You can approve it, edit it inline or reject it with feedback, which sends it back for another pass. Only after approval does the task creator split it into subtasks, at most 8 in total.
Choosing the model
This is one of the roles a workspace can pin to a specific model. A single job can override that pin while it is idle, or failed before re-planning. A hard change can then get a stronger model without changing the default for everyone.
The image decision
Before the run starts, a separate image decider may pick the container image each repository runs in. It sees only the root file listing and manifest paths, never file contents, and its errors never fail the task.
FAQ
Does the DevFlow planner change any code?
No. The DevFlow planner reads and explores; code is written later by the implementer, inside the task's worktree.
Why does the DevFlow planner stop to ask questions?
A wrong assumption in a plan costs more than a short answer. The DevFlow planner batches its questions so you can settle scope before any subtask is created.