Multi-session Workflow

Multi-session work is useful when tasks can move independently. It is risky when multiple agents edit the same files without ownership boundaries.

Use Worktrees For Isolation

A clean pattern is one intent per worktree:

git worktree add ../repo-i18n-en -b feat/i18n-en
git worktree add ../repo-tests -b test/i18n-routing

Each session gets a clear role:

• Main session: integrates decisions and resolves conflicts.
• Implementation session: owns a specific file set or feature area.
• Verification session: runs checks, captures failures, and reports concrete evidence.

Session Brief

Start every parallel session with a small contract:

You own only apps/handbook/app and apps/handbook/lib.
Do not edit content files.
Goal: make route generation locale-aware.
Report changed files and verification results.

The narrower the contract, the less coordination overhead the main session has to absorb.

Handoff Format

Ask every session to end with the same fields:

• Files changed.
• Behavior changed.
• Commands run.
• Known risks.
• Follow-up work.

This makes integration review mechanical instead of conversational.

Conflict Control

Avoid parallel edits to these areas unless one person owns the merge:

• Shared type definitions.
• Generated source files.
• Root package metadata.
• Test fixtures used by multiple suites.
• Route or middleware files that affect every request.

When Not To Use It

Do not split work when the next step depends on the result of a single unknown. Investigate the blocking question locally first, then delegate once the shape of the change is clear.