multi-agent

name	multi-agent
description	Defines the explicitly parallel @samchon/graph variants of review and issue campaigns. Use only when the user explicitly requests a team, parallel, or multi-agent review or issue campaign. Route review work to review.md and issue campaigns to issue-campaign.md. Self-Review, unqualified review, and a campaign without explicit parallel authorization remain solo.

Multi-Agent Workflows

This skill is the single entry point for every explicitly parallel review or issue campaign. Read the base solo skill first, then enter through the detailed document below for the requested workflow.

Explicit request	Base skill	Detailed multi-agent procedure
Team, parallel, or multi-agent review	review	review.md
Parallel or multi-agent issue campaign	issue-campaign	issue-campaign.md

This repository has a benchmark runner, not a benchmark-campaign workflow. The benchmark skill continues to govern its measurements; do not invent a parallel benchmark-campaign variant.

Do not load this skill for Self-Review, an unqualified review, or a campaign that does not explicitly request parallel agents.

Shared Parallelism Rules

• Use the smallest number of agents that adds independent evidence or owns immediately executable disjoint work. Available thread capacity is not a reason to create an agent.
• Never create a waiter, poller, coordinator-only child, duplicate implementation owner, or agent that cannot begin useful work immediately.
• Give every review or discovery agent the complete declared surface. Parallel review adds independent full passes; it never partitions coverage by package, file, concern, platform, or test lane.
• Partition implementation only through verified dependency and file-ownership boundaries. One agent owns one coarse batch, branch, pull request, and worktree.
• Keep the lead active on fact-checking, integration, conflict resolution, and decisions that do not duplicate an assigned agent.
• Do not let agents re-delegate.
• Self-Review remains solo for every author and every implementation branch.
• Create worktrees only for parallel implementation batches and their integrated cleanup. Solo implementation uses the current checkout and one topic branch.
• Remove every finished worktree, local branch, process, and assignment-owned temporary asset before declaring its assignment complete.

The solo campaign's commit early-warning pass is a different topology and relaxes neither the full-surface rule nor the solo Self-Review rule above. A parallel review gives several reviewers the entire declared surface independently and the lead adjudicates their findings. The pass gives one read-only reader one commit's slice, reports candidates to the author who is still implementing, and leaves that author's own whole-surface round as the gate. A batch implementation agent here runs no pass, because agents do not re-delegate; the requirement belongs to a solo campaign's main agent.

The user's phase boundary controls the topology. A multi-agent issue campaign uses parallel discovery and parallel implementation by default. Switch only its implementation to the solo workflow when the user explicitly requests parallel discovery with solo implementation.