Give each reviewer a distinct scope
Parallel review is most useful when each Pi child has a clear boundary. For example, one specialist can inspect UI behavior and another can trace API or persistence behavior. Share the commit or diff to review, identify excluded files, and ask both reviewers to return findings rather than broad summaries. Their separate session contexts make follow-up possible without asking the same questions from scratch.
First inspect your current changes and working tree so you know what is being reviewed. The child sessions use the project directory by default; pi-subagentura does not create a separate Git worktree automatically. If both scopes touch the same files, make that overlap explicit.
Launch two focused reviewers
Ask the parent Pi agent to start two interactive children concurrently. Set background: false on each call if you want to watch both in visible panes. If the review depends on decisions in the current parent conversation, pass that context with includeContext: true; otherwise include the necessary review brief in each task.
The following task prompts are examples to adapt, not completed reviews:
Frontend reviewer example
Review the changed frontend routes and components in this diff.
Stay within the UI scope: look for behavior regressions, accessibility issues,
and mismatches between visible controls and their actual behavior.
Do not edit or format files. Return only actionable findings with severity,
file and line, impact, and specific evidence. If you find none, say so.Backend reviewer example
Review the changed API, data, and server-side code in this diff.
Stay within the backend scope: trace inputs through validation and persistence,
and look for correctness or error-handling gaps.
Do not edit or format files. Return only actionable findings with severity,
file and line, impact, and specific evidence. If you find none, say so.Two calls to subagent_interactive let the parent keep both reviews inspectable as they work. These are separate Pi processes, so starting the second does not require waiting for the first to finish. The parent remains responsible for comparing their findings and deciding which points to investigate.
A read-only request is still a request
“Do not edit” in a task prompt or persona is guidance for the model, not an enforced tool-permission boundary. pi-subagentura does not automatically import arbitrary agent-definition files or tool allowlists into the child. A child may have tools capable of changing files, depending on the Pi environment and extensions you use.
Both reviewers also share the parent project working directory by default. A separate child process does not mean a separate checkout: changes made by one child can be visible to the other. If the review must remain read-only, check git status before and after, inspect the diff for unexpected edits, and handle any required isolation separately.
Ask for evidence, then follow up in the same session
Prefer findings with a concrete file and line, a user or system impact, and evidence from the code path. If a report is unclear, send a follow-up to that same interactive child to check the specific path or explain why the behavior is a defect. The child keeps its own conversation context across follow-ups; it does not need the parent to repeat its entire task. The parent should still verify important findings before acting on them.
Open /subagents or press Ctrl+Alt+A to inspect the reviewers; v captures a terminal snapshot,f focuses a pane, and a displays its attach command. See the install guideor tmux and Zellij guidefor setup and lifecycle details.
Read the released READMEfor supported tool behavior. Continue to the product overview,session walkthrough, orPi subagents overview.
This tutorial describes pi-subagentura 4.2.1; package metadata was verified 2026-11-07. The prompts are examples, not reports of completed reviews.