Work in parallel

Multiple threads in a single Friday session, each editing in its own worktree, merged back through the queue. This recipe is for shipping one feature faster by splitting its work across threads. It is not for working on different features at once.

Friday is designed as one session per branch and PR. To work on a different branch concurrently, launch a separate Friday session in its own worktree instead. See Parallelize work with worktrees.

This recipe covers what to type and what to expect. For how it works underneath, see Dispatch, threads, and subagents.

When parallel makes sense

Independent or weakly-coupled work: different modules, different files, different layers. Two threads editing the same file are likely to conflict on cherry-pick, so split the work along clean seams.

If the tasks are tightly coupled (shared types, sequential dependencies), do them one after another in a single thread instead.

Spawn the threads

Two ways. Pick whichever matches the work.

Let Dispatch fan out. Tell Dispatch what you want done in parallel; it spawns the threads itself. Each thread shows up in the ThreadList named after its task ("Refactor auth", "Update API endpoints"), so they're scannable at a glance.

Spawn manually. Click + New Thread in the bottom-left, or run /fork <description> to start a thread that carries the current conversation forward. Manually-spawned threads get a generic auto-name; rename with /name <new name>.

Watch the threads

Click any thread in the ThreadList to switch into its pane. Each thread is its own conversation. The list shows three visible cues:

● in front of a thread that's asking for your attention.
⏳ on a thread queued for merge.
✓ Merged once a thread has been cherry-picked back.

You can keep typing in Dispatch while threads work. New messages queue up.

Talk to a thread mid-flight

Click into the thread's pane and type. Or, from Dispatch, ask it to send a message. Threads can ask back: if a thread is blocked, it surfaces a question in Dispatch.

Review what each thread did

Before accepting, you usually want to see what each thread actually wrote. See Review thread changes for how to inspect each thread's diff.

Accept the changes

When a thread finishes, it calls AcceptThread and the merge queue cherry-picks its commits onto your current branch. In Collaborative mode you'll see a "Ready to accept this thread?" prompt the first time per thread. In Supervised and Autonomous, the cherry-pick happens silently.

If a parallel dispatch leaves you with one prompt per thread, you're in Collaborative mode. Switch in /settings to merge end-to-end, or read Dispatch / Accepting a thread's changes for the full breakdown of which gates are at play.

Conflicts

If a cherry-pick fails because two threads touched the same lines, Friday aborts and reopens the thread with a conflict summary in its pane. Continue the conversation in that thread to resolve; it will retry AcceptThread.

If the cherry-pick fails because your current branch has uncommitted changes, same fallback: Friday won't overwrite your in-flight edits.

Common pitfalls

Multiple accept prompts queued up. Working Style is Collaborative. Approve them, or switch to Supervised/Autonomous in /settings.
A thread won't merge. Check its pane. If there's a conflict summary, continue the conversation. If AcceptThread is waiting for input, the prompt is in the thread's pane (not Dispatch's).
Two threads touched the same file. The second cherry-pick will likely conflict. Serialize the work or rebase by hand.
You spawned a thread you no longer want. Tell Dispatch to abandon it, or use the abandon flow inside the thread's pane.
You forgot a thread is open. /tasks shows orphans. Abandon what you don't need before exiting; otherwise Friday WIP-commits and leaves the branch behind.