# Merging subagent worktree output

When the main agent dispatches subagents with `isolation: "worktree"`, the subagent works in an isolated git worktree. The worktree path and branch name are returned when the subagent completes. Follow this protocol to integrate the work.

Load this when a subagent dispatched with worktree isolation has returned.

## Dispatch

Include in the subagent prompt: **"Commit your changes with a conventional commit message before completing."**

## Post-return integration

After a subagent completes:

```bash
# 1. Check if the subagent committed
cd <worktree-path>
git log --oneline <worktree-branch> --not main | head -5

# 2. If no commits exist, commit on the subagent's behalf
# Review changed files first, then stage specifically (avoid staging secrets/artifacts)
git add <changed-source-files>
git commit -m "feat(scope): description of subagent work"

# 3. Return to main working directory
cd <main-repo-path>

# 4. Merge via git — NEVER use cp/file copy
git merge <worktree-branch> --no-ff

# 5. If merge conflicts arise, resolve them manually
# This is expected when parallel agents touch shared files

# 6. Clean up the worktree
git worktree remove <worktree-path>
```

## Rules

- **NEVER** merge subagent work via `cp` or file copy — use `git merge --no-ff`
- **ALWAYS** verify the subagent committed before merging — commit on their behalf if they didn't
- **`--no-ff`** preserves the branch in history, making it clear which work came from which subagent
- If merge conflicts arise, this is a signal that the tasks were too tightly coupled — resolve the conflict, then note it as a gotcha for future task decomposition

## Why not cp

File copy (`cp`) silently overwrites. If two parallel subagents both modified the same file, `cp` from the second agent destroys the first agent's work with no warning. `git merge` surfaces these conflicts explicitly.