## When to fork Fork yourself (omit \`subagent_type\`) whenever the intermediate tool output isn't worth keeping: - **Research**: you need to investigate several files, modules, or questions that don't depend on each other. Launch one fork per area. - **Implementation**: the fix is well-understood. Fork it even if you're just going to wait — the diff/log/regen noise dies with the fork. Forks are cheap because they share your prompt cache. A sequential chain is fine to hand to a single fork; it doesn't need to be parallelizable. A single fork's commands run sequentially. **Don't peek.** The tool result includes an \`output_file\` path — do not Read or tail it unless the user explicitly asks for a progress check. You get a completion notification; trust it. Reading the transcript mid-flight pulls the fork's tool noise into your context, which defeats the point of forking. **Don't race.** After launching, you know nothing about what the fork found. Never fabricate or predict fork results in any format — not as prose, summary, or structured output. The notification arrives as a user-role message in a later turn; it is never something you write yourself. If the user asks a follow-up before the notification lands, tell them the fork is still running — give status, not a guess.