TermdockThree Tasks, Clearly Bounded
This illustrative e-commerce project assigns product search, a shopping cart, and order-confirmation email to three Claude Code sessions. Establish a shared spec, work in separate Git worktrees, then inspect diffs, tests, and integration order.
This is an adaptable workflow, not a verifiable run. An earlier version claimed completion in 40 minutes with all tests passing but provided no execution record; those figures are not presented as results here. Parallel work is not guaranteed to be faster, and integration and review still take time.
Prerequisites
Use a practice repository you are authorized to modify that already has a commit. Install Git, Claude Code, and Termdock; check Claude Code account eligibility, usage, and permissions. Run git status and git worktree list, inspect existing changes and worktrees, and protect uncommitted or irreplaceable data. The example branches and destination directories must not already exist; stop and investigate rather than overwrite them.
Worktrees are separate working directories but share the Git repository. They are not a security sandbox. Use appropriate permissions or isolation for credentials, network access, and files.
Step 1: Confirm the Shared Spec
Define the three requirements, shared types, API interfaces, allowed files, and test commands. Confirm the spec is in the selected base commit and that the local state is safe to use. Do not overwrite an existing type file with cat >; read it, keep a backup, and decide whether to commit any shared changes yourself.
For example, assign search to app/search/ and lib/search/, cart to app/cart/ and lib/cart/, and email to lib/email/. If all need app/layout.tsx or shared configuration, assign one owner before concurrent edits.
Step 2: Create Worktrees and Open Termdock
This uses the current HEAD as the common base. First confirm it is the commit you inspected. These commands create new branches, not check out existing ones:
git worktree add -b feature/product-search ../project-search HEAD
git worktree add -b feature/cart ../project-cart HEAD
git worktree add -b feature/order-email ../project-email HEAD
git worktree list
Open three terminals in Termdock, enter the corresponding directories, and check pwd and git status before starting the installed claude CLI in each. Termdock recognizes existing worktrees but does not automatically create one per agent.
You can alternatively use claude --worktree <name> according to the Claude Code worktree documentation. Claude Code manages that path and branch, with a worktree- branch-name prefix by default; the base commit and cleanup behavior also depend on settings and version. Do not assume it creates the manual feature/... branch names above.
Step 3: Give Each Agent a Bounded Task
Each session needs the shared spec and its own responsibility. For example:
Implement product search according to the committed spec.
Edit only [insert authorized files or directories]; do not edit shared
configuration or another agent's files. Run [insert verified test commands].
Report your branch, diff, actual test results, and unfinished work.
Do not commit, merge, or deploy unless I explicitly ask.
Replace the brackets with real values and provide separate scopes for cart and email. For external email services, use a test setup first; do not send real mail without authorization.
Step 4: Hand Results Off in Termdock
Once the agents report back, give the coordinator all three worktree paths, branches, diffs, test output, and open questions. Ask it to check shared types, dependency order, and overlapping files, then list items needing human judgment. Pass the material manually, or use the Termdock CLI/API handoff walkthrough so an agent can send tasks and read responses.
Sessions do not automatically share context, and a terminal going quiet does not prove success. Check the actual files and tests; mark missing results for follow-up.
Step 5: Review, Integrate, and Verify
Inspect git status and the diff in each worktree and confirm changes stay within the authorized scope. Decide whether to commit and merge each branch in the verified dependency order. Resolve conflicts individually rather than assuming they will always be automatic.
After integration, run the project's actual build and relevant tests and inspect the browser when needed. Keep the commands and results. Confirm that the email flow uses test data and a test service. Only report tests as passing when they actually passed; list failures and checks not run.
Step 6: Clean Up Only After Checking
Before cleanup, inspect git worktree list, uncommitted and untracked files in every worktree, and any unmerged commits. Create and verify a readable backup of irreplaceable or user-owned data; Git is not a backup. After confirming that work is preserved and cleanup is authorized, use the Git worktree documentation to remove no-longer-needed worktrees or branches.
When Parallel Work Is Worth Trying
It fits tasks with clear ownership, separate validation, and enough capacity to review integration. If work is tightly dependent, shares many files, or accesses sensitive systems, a sequential approach may be simpler. Record your own time, tests, rework, and usage before deciding whether the setup helps.