Working on ten things rarely means ten things happening at the same instant. It means ten things you're responsible for remembering to get back to. The tenth idea on your list isn't waiting on any real constraint — it's waiting on you having a free hour, remembering where you left off, and deciding what's next.
The fix isn't parallelism at the code level. Building ten related features against the same codebase at once is a fast way to spend an afternoon resolving conflicts nobody needed to create — that's the right shape for independent ideas run side by side, not for a backlog of changes to one project. The fix here is a workspace that holds nothing but a list — a roadmap, numbered in whatever order you'd actually want it tackled, with an item checked off only once it's truly merged in.
One agent, a Conductor, is the only one that ever ticks against that list on its own schedule — a `scheduled` trigger, since it has no thread to wait on and has to go check the roadmap itself. Its only job is sequencing: once the current item lands, it opens a fresh child workspace for the next unchecked one, branched from wherever the roadmap's own worktree already sits, and briefs whoever builds it with exactly the item it owns. It never opens an editor itself.
Building happens in that child workspace, by an Engineer agent (`unread` trigger) that iterates until it believes the feature is genuinely done. It doesn't get to decide that alone, though — it hands off to a separate Reviewer, in a workspace of its own, that checks the work against what was actually asked before anything merges. Feedback travels back the same way it arrived: a message left in the Engineer's own thread, not a verdict delivered from nowhere.
That hand-off matters more than it sounds like it should. A Conductor that just replies to a thread itself, or an Engineer that reviews its own work, collapses the entire point of having separate roles — you'd be trusting the one agent that already believes it's finished to also be the one that checks. Keeping the roles in separate workspaces, talking only through messages left in a thread, is what makes "done" mean something other than "the agent that built it says so."
None of this caps out at ten. Add an eleventh item to the list whenever the eleventh idea shows up, and the Conductor treats it exactly like the tenth — nothing about the setup assumes a fixed count, or that you'd already decided everything up front.
What actually changes for you isn't how fast any single feature gets built. It's that ten things can be genuinely moving forward without ten things sitting open in your head at once — you get to add to the list and come back later, instead of being the thing every item is quietly waiting on.
Q: Does this mean DF Code builds multiple features at the same time? A: Not against the same codebase, deliberately — a roadmap's Conductor keeps only one feature past the Engineer stage in flight at a time, since building two related features on top of each other invites exactly the kind of conflict a real team would avoid too. What scales is how many items can sit queued without needing your attention, not concurrency at the code level.
Q: How is this different from running several parallel workspaces for different ideas? A: Independent ideas that don't depend on each other can run as fully separate, simultaneous workspaces with no coordination needed — every workspace gets its own worktree, so nothing about the platform stops them running at once, even against the same repo. A roadmap is the opposite case on purpose: a backlog of related changes to one codebase, where each item builds on the last, so a Conductor deliberately holds the next one back until the current one's merged — a workflow choice to avoid two dependent changes racing each other, not a limit on what worktrees can actually do.
Q: What triggers does a setup like this actually use? A: The Conductor uses a `scheduled` trigger, since it has no thread to wait on and has to go check the roadmap itself; the Engineer and Reviewer both use `unread`, reacting whenever a new message lands in their own thread.
Q: How does a finished feature actually reach the Reviewer? A: The Engineer opens a new thread in the Reviewer's own workspace and posts a self-contained summary to it — never by replying to itself or triggering a generic run — so the Reviewer's own configured agent picks it up on its own polling cadence, correctly attributed to it in the audit trail.