Understand Parallel Agent Work
To review parallel work, you need to know what changed, which tasks depend on each other and which checks are missing.
Use a separate CLI session to investigate one question using the same repository and task records. This is a suggested workflow, not a measured user-study result.
Ask What You Need to Decide
Choose an uncertainty in the current work: an unexpected file change, a blocked task or overlapping reviews. Ask the CLI to explain it using task and repository records.
Name the project, task IDs and source revision. Ask for links to diffs, logs or decisions. An answer becomes useful when you can inspect its basis and decide what follows.
Define the Reading Scope
Start with read-only access. Supply the records needed for the question and state which information is unavailable. Decide separately whether the CLI may propose or perform an API update.
- Ask for observations and assumptions to be distinguished.
- Include relevant task history when the reason for a change matters.
- Keep credentials and unrelated project data outside the reading scope.
Investigate Two Overlapping Changes
Choose two tasks that touched the same subsystem. Ask for a map of the files each task changed, with links to the diffs. Check whether they changed a shared interface and whether the recorded tests cover the combined behavior.
If a test is missing, create a task for that specific gap. If the changes are independent, record the evidence behind that conclusion. The map is a reading aid; the diffs and checks support the decision.
Save the Conclusion with Its Sources
Save the explanation that helped you decide, along with source revisions, evidence links and unresolved questions. A later reviewer should be able to follow the conclusion after the CLI session ends.
- A task-and-file map for related changes.
- A note naming an untested behavior.
- A clarified acceptance criterion or a focused follow-up task.
Separate Inspection from Changes
A second CLI can inspect the same repository and task records. Define what it may read and which updates it may propose. Granting task write access adds responsibility for scope, state and the review record.
Check proposed updates before they reach the board. A plausible summary can omit a fact or misread a dependency. Keep the underlying records available.
Make the Next Action Visible
Accept the result, clarify the task or create a follow-up through the normal task workflow. If a fact or check is missing, name it explicitly. Keep the explanation beside the decision.
Use the external CLI pattern when the other tool implements changes. Use this workflow when it helps you understand and review work already in progress.