# How I use `/tree` and `/spawn` to investigate bugs

post · 2026-06-30

import PiSessionLink from '@components/content/PiSessionLink.astro';
import InvestigationTreeDiagram from '@components/posts/how-i-use-tree-and-spawn-to-investigate-bugs/InvestigationTreeDiagram.astro';
import SpawnHandoffDiagram from '@components/posts/how-i-use-tree-and-spawn-to-investigate-bugs/SpawnHandoffDiagram.astro';

Adapted from a [Twitter thread](https://x.com/aliouftw/status/2052312438196846984).

I love [Pi](https://pi.dev)'s `/tree` and `/fork` commands, but I also like having a clean context when moving from investigation to implementation. So I made a [`/spawn`](https://github.com/aliou/pi-harness/tree/71cb5277f2baa04813896320bdfdaf4adb34ebff/commands/spawn)[^handoff] command that simply creates a new child session with the last message of the parent session. Here's what it looks like in a [PR to investigate a bug in Pi](https://github.com/earendil-works/pi/pull/4234).

I usually use `/tree` when I'm investigating bugs. Let's say you find a weird behaviour and the issue could be from different places. The agent gives you a message A that summarizes the different candidates 1, 2 and 3.

I'll then tell the agent to focus on candidate 1. We'll investigate, repro, try to fix it etc. until we figure out if it's the bug. Then, I rewind back to message A, with a summary of our findings. The summary is a new message, A-1.[^2]

[^2]: Usually I would also discard the code here; the summary often includes the important snippets.

You then do the same for each candidate and rewind back to the summary of the previous branch: you then get A-2 and A-3.

<InvestigationTreeDiagram />

<PiSessionLink href="https://pi.dev/session/#08bc0557ec50e22183d1a631ee63bbe5" label="Here's what that investigation issue looks like" />

From there, you can continue on a new branch and refine your understanding of the bug and start brainstorming an actual fix, and/or even investigate further: for example if the bug is actually a mix of the candidates you've identified first.

Usually, I would have the agent add a failing test or create a repro-script, and then explain the bug fully with the full context. Then I would `/spawn` a new session with only that bug explanation, none of the research above + the repro and ask another agent to research / implement the bug.

<SpawnHandoffDiagram />

Once I had the bug pinned down, I spawned a second session to implement the fix:

<PiSessionLink href="https://pi.dev/session/#64ddc3dc9e1c29d61d69f091e87bb303" label="Here's how that spawned session would look like" />

This way, the second session starts with just the right amount of context. In addition, this will also be the place where I will switch to a different model, usually a cheaper and/or faster one, because all of the unknowns have already been figured out by the model in the previous session.

In addition, I've also found that when I leave my agents to loop this workflow works pretty best by having an orchestrator agent that will spawn a first implementation agent and then have these agents be in charge of handing off or spawning the new implementation agent with the result of the initial investigation. The only difference is that I am no longer in the loop and I leave the agent to do that delegation work by itself.

[^handoff]: Poor man's version of [Amp's `/handoff`](https://ampcode.com/news/handoff).