Aliou Diallo
post

How I use /tree and /spawn to investigate bugs

Adapted from a Twitter thread.

I love Pi’s /tree and /fork commands, but I also like having a clean context when moving from investigation to implementation. So I made a /spawnPoor man’s version of Amp’s /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.

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.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.

Branching investigation workflow Message A branches into three candidate investigations. Each branch produces a summary (A-1, A-2, A-3) that is carried forward as a new message on the main line. A root message candidate 1 investigate candidate 2 investigate candidate 3 investigate A-1 summary A-2 summary A-3 summary summaries carried forward

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.

Spawn handoff to a clean implementation session A parent session distills its research into a bug summary plus a repro, then spawns a clean child session that carries only that summary and the repro forward to implement the fix. parent session clean child session findings research bug summary + repro repro + test implementation /spawn

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

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.