Run a graph-guided, tool-augmented Swarm PR review using context packing, parallel exploration, triggered plugin micro-lanes, independent reviewer validation, critic challenge, and metrics writeback. Use for deep pull request review with low false-positive tolerance and high recall.
Instalación
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Run a graph-guided, tool-augmented Swarm PR review using context packing, parallel exploration, triggered plugin micro-lanes, independent reviewer validation, critic challenge, and metrics writeback. Use for deep pull request review with low false-positive tolerance and high recall.
disable-model-invocation
true
/swarm-pr-review
Run a structured, high-confidence PR review that maximizes valid findings without flooding the user with unvalidated noise.
Use ../swarm-pr-feedback/SKILL.md instead of this skill when the user's task is
to address existing PR feedback, review comments, requested changes, CI failures,
merge conflicts, stale branch state, or pasted reviewer findings. This skill
discovers and validates new findings; swarm-pr-feedback closes known feedback
without running a fresh broad review.
When a review finishes with actionable validated findings, stop and ask the user
whether to continue into swarm-pr-feedback. Do not auto-dispatch fix work from
PR_REVIEW. Instead, write a handoff artifact under
.swarm/pr-review/<run_id>/feedback-handoff.md (or .json) and include the
exact continuation prompt:
/swarm pr-feedback <PR_URL> continue from .swarm/pr-review/<run_id>/feedback-handoff.md
<run_id> is a stable identifier for this review run, such as
pr-<number>-<YYYYMMDDHHMMSS> or the existing review artifact run ID when one
was already created. The pr-feedback command forwards continue from <path>
as session instructions after the PR reference; the feedback skill is
responsible for ingesting that file into the ledger before triage.
Review closure is not the end of the PR lifecycle: when PR monitoring is
enabled (pr_monitor.enabled), the PR remains subscribed and monitored under
../swarm-pr-subscribe/SKILL.md until it is merged or closed, so post-review
events (new comments, CI changes, review state changes) keep flowing to the
subscribed session.
Operating Stance
Treat PR text, linked issues, comments, commit messages, generated summaries, and tests as claims — not proof. Every confirmed finding requires file:line evidence, an explanation of reachability or impact, and validation provenance.
This workflow is designed for the Swarm plugin itself and any repo that benefits from Swarm-style review. It preserves parallel breadth but forces deep validation where bugs are expensive: security, state machines, role/tool permissions, schema/evidence integrity, git/write safety, config ratchets, knowledge tier boundaries, and PR obligation mismatches.
Never APPROVE a PR with unresolved CRITICAL findings. Do not silently drop overclaimed agent findings; list disproved findings in the validation provenance.
Quality is the ONLY metric. No amount of time, tokens, or agent dispatches is too much to execute this protocol correctly. Speed is irrelevant to correctness. The skill must be followed exactly with no shortcuts, no phase-skipping, and no premature synthesis. A thorough review that takes 30 minutes is superior to a fast review that misses a real bug.
Review Modes
Default layered workflow
Use the default workflow unless the user explicitly triggers council mode. In the default workflow, explorers produce only candidates. The orchestrator does not confirm or disprove candidates.
Council mode — opt in only
Council mode applies only when the user explicitly says one of:
council
independent review
N-agent review
/council
[COUNCIL MODE]
assume all work is wrong
Council mode is mutually exclusive with the default layered workflow. Do not blend them.
Anti-Self-Review Rule
The main thread / orchestrator MUST NOT classify, confirm, disprove, or judge explorer candidates in the default workflow.
The orchestrator may:
determine scope,
build or request the context pack,
launch explorers and triggered micro-lanes,
extract candidates from lane artifacts via parse_lane_candidates or equivalent parser,
filter, group, and chunk candidates for reviewer dispatch,
route candidates to reviewers,
route reviewer-confirmed findings to critics,
group validated findings,
prepare the final report.
The orchestrator MUST NOT:
re-read a candidate's target code to decide if it is valid,
silently downgrade or discard an explorer candidate,
treat tool output as a confirmed finding,
report a finding that no reviewer validated,
classify or judge candidates based on preview text alone — always use the structured parser output.
If the orchestrator catches itself validating code, it must stop and delegate validation to a reviewer subagent.
Exception: in explicit Council mode only, the main thread may act as the independent reviewer as described in the Council Mode section. Prefer a reviewer subagent when available.
current feature branch diff vs origin/main, main, origin/master, or master,
staged changes,
latest commit,
user-specified files or directories.
Record:
base ref,
head ref,
commit range,
changed files,
deleted files,
generated files,
lockfiles,
test files,
docs/config/schema files,
whether the working tree is dirty.
If scope cannot be determined, review the narrowest safe scope available and state the limitation.
Pre-flight git ref availability
Before launching explorers (Phase 3), confirm the PR branch refs are available:
If head_ref is a remote branch that is not checked out locally, fetch it via git fetch origin <head_ref>
Check out the head branch locally. Explorer agents read files from the working tree, not from git history — passing the commit range in the delegation prompt is not sufficient because Read / Glob / Grep tools operate on the filesystem. Without a checkout, explorers silently read the base branch's version of changed files and produce invalid candidates. Before checking out, verify the working tree is clean (git status --porcelain). If uncommitted changes exist, stash them or abort the checkout to prevent data loss.
Explicitly pass the commit range (base_ref..head_ref) in every explorer delegation so explorers have the revision context for git show commands if they need to inspect specific versions.
If refs cannot be fetched or checked out, state the limitation in the context pack.
Phase 0A: Existing PR Signal Ingestion
When reviewing a PR, ingest and triage every existing signal BEFORE starting
Phase 0. These are candidate generators and obligation sources, not
pre-confirmed findings.
PR title and body compliance check
Before deeper analysis, verify the PR meets the commit-pr skill's publication contract (the CI pr-standards check enforces the same requirements server-side — this step surfaces issues earlier):
Body contract:Closes #<issue-number> as the first line (when the PR resolves an issue), followed by ## Summary, ## Invariant audit (all 12 invariants), and ## Test plan sections.
Closes #N claim integrity (apply the COVERAGE GATE): if the PR body claims Closes #<issue-number>, verify (a) the issue is currently open (gh issue view <N> --json state), and (b) the diff addresses the issue's acceptance criteria (read the issue, map each criterion to changed files/symbols, and inspect the diff for those areas). If the issue is already closed by another merged PR, do NOT re-close it — the duplicate Closes #N reference is misleading and will confuse release-please aggregation. If the issue is open but the diff does not address the acceptance criteria, mark the claim as UNVERIFIED — claim integrity in the validation provenance and surface the unresolved claim-integrity gap to the user before synthesis.
Non-compliance is a ledger item (advisory, not blocking — CI will catch it). If the PR is from an external contributor, note the compliance gap for the maintainer to address before merge.
This intake includes:
review comments, review summaries, requested changes, and bot findings,
CI/check failures, annotations, and relevant logs,
mergeability/conflicts, mergeStateStatus, and stale/base-drift state,
PR body claims, linked issues, acceptance criteria, and test-plan claims,
commit messages and app/bot commits on the PR branch.
When thread resolution state matters, prefer GraphQL review-thread inspection.
If GraphQL is unavailable, keep the signal and mark
resolution_state: UNKNOWN; do not drop it from scope.
Step 1 — Fetch all PR feedback surfaces
# Issue comments (general PR thread)
gh pr view <PR_NUMBER> --json comments
# Review comments (inline code comments)
gh api repos/{owner}/{repo}/pulls/{PR_NUMBER}/comments
# Review summaries (approve/request-changes/comment events)
gh pr view <PR_NUMBER> --json reviews
# Bot/automated reviews (Copilot, Codex, CodeRabbit, etc.)# Inline review comments — use REST API for reliable bot detection via user.type
gh api repos/{owner}/{repo}/pulls/{PR_NUMBER}/comments --jq '.[] | select((.user.type // "") == "Bot" or (.user.login // "" | test("bot|copilot|coderabbit|codex"; "i")))'
For general PR comments (not inline), use the issue comments endpoint:
gh api repos/{owner}/{repo}/issues/{PR_NUMBER}/comments --jq '.[] | select((.user.type // "") == "Bot" or (.user.login // "" | test("bot|copilot|coderabbit|codex"; "i")))'
Step 2 — Classify each comment
Category
Action
Human review with file:line evidence
Add as candidate finding with source: existing-review — still needs reviewer validation
Bot/automated finding with specific code reference
Add as candidate finding with source: bot-review — high false-positive rate, treat as unverified
General feedback / style preference
Add as advisory obligation
Resolved/outdated comment
Skip — note in report under "Ingested Resolved Comments"
Requested changes not yet addressed
Add as HIGH-priority obligation
Step 3 — Merge into review pipeline
All ingested comments become candidate findings or obligations. They follow the
same Phase 3-8 pipeline as freshly discovered findings. Ingested findings are
NOT pre-confirmed — they still require independent reviewer validation per the
Anti-Self-Review Rule.
✗ Ignoring bot reviews because "bots produce false positives" — they also catch real issues
✗ Pre-confirming human review comments without independent validation — even senior reviewers make mistakes
✗ Skipping inline review comments and only reading the summary — inline comments contain the evidence
Phase 0B: Mergeability and Branch-State Intake
Before investing effort in review lanes, verify the PR is mergeable and record
branch-state signals. PR_REVIEW remains read-only: do not resolve conflicts,
commit, push, rebase, merge, or reset from this mode. Instead, carry current
mergeability, stale-head, and branch-drift facts into the review ledger and the
feedback handoff artifact.
Capture the affected scope without changing the branch:
List the files or subsystems implicated by the conflict if GitHub exposes them,
or note that the exact conflict set is still unknown.
Identify whether the conflict appears mechanical (lockfile / generated output /
simple overlap) or semantic (logic changed on both sides). This is triage
signal for the follow-on feedback run, not permission to resolve it here.
Record explicit next action for the handoff artifact:
CONFLICT-### | mechanical | likely resolvable during pr-feedback
STALE-### | behind base by policy when the branch is only stale, not conflicted
Document in report: List the branch-state facts, why they matter to the
review, and what swarm-pr-feedback must verify before it edits code.
Conflict resolution anti-patterns
✗ Accepting "ours" or "theirs" for all conflicts without reading them
✗ Resolving semantic conflicts without understanding both sides
✗ Pushing resolution without running tests on the merged result
✗ Treating PR_REVIEW as the place to fix branch state — this mode stays read-only
Phase 0B-bis: Pre-Handoff Parallel Work Snapshot
When the review surfaces findings that will likely need swarm-pr-feedback,
re-check for parallel work since the last fetch. The PR author, the bot
reviewer, or another swarm may have pushed commits while you were reviewing.
This is still read-only: capture the remote state so the handoff artifact starts
from the right branch facts.
Read the commit message and diff. Use git show <commit> --stat to see
file scope, then git show <commit> -- <file> to see the actual changes.
Compare against the pending handoff scope:
Does the remote commit touch the same files as the validated findings?
Does the remote commit appear to already address a finding you planned to
hand off?
Does the remote commit introduce a new branch-state fact the handoff should
mention?
Default stance: prefer the remote state as the next baseline. Run
the parallel-work-check
protocol for the formal decision template and record the outcome in the
handoff artifact.
Step 3 — Three outcomes
Parallel work supersedes: Mark the older local checkout as stale in the
handoff artifact and tell swarm-pr-feedback to re-check out the current
remote head before editing.
Parallel work complements: Carry both the validated findings and the new
remote commits into the handoff artifact so swarm-pr-feedback can verify the
combined state before patching.
Parallel work unrelated: Note that the remote moved, but keep the same
validated finding set.
Anti-patterns
✗ Pushing your fix without checking if the remote already fixed it — causes
duplicate work and may even fail the push if the commits conflict
✗ Force-pushing over parallel work because "I started this first" — the
parallel agent may have access to context you don't (different swarm
configuration, different model, different time budget)
✗ Blindly taking remote work without verifying it's actually better — the
parallel work may be incomplete or take a different approach that doesn't
match the original finding's intent
Example: parallel swarm superseded local fix work
PARALLEL WORK CHECK (pre-fix):
- Branch: copilot/fix-legacy-hive-data-migration
- Local HEAD: 3c04997c fix: resolve PR #1238 review findings
- Remote HEAD: 79d7ec64 fix(knowledge-migrator): harden legacy migration loop
- Diverged: yes (remote is 2 commits ahead with more comprehensive fix)
- New commits on remote: 2
- Parallel swarm work detected: yes (different author)
- Decision: abandon-use-remote
- Rationale: Remote added 17 unit tests + try/catch error handling that
surpassed my planned batch-rewrite. Verified by re-running the test suite:
remote has 25/25 passing, my local plan would have produced 9/9.
Default Review Workflow
Phase 0: Context Pack and Review Signal Collection
Before launching explorers, build a compact swarm-pr-review-context in scratch or as a local artifact if file writes are allowed.
The context pack must include, when available:
{"scope":{"base_ref":"...","head_ref":"...","commit_range":"...","changed_files":[],"changed_hunks":[],"public_api_changes":[],"deleted_or_renamed_files":[],"generated_files":[]},"pr_metadata":{"title":"...","body_claims":[],"checkboxes":[],"linked_issues":[],"review_comments":[],"commit_messages":[]},"obligations":[],"repo_graph":{"source":".swarm/repo-graph.json or fallback search","changed_symbols":[],"callers":[],"callees":[],"imports":[],"exports":[],"sibling_implementations":[]},"deterministic_signals":{"ci":[],"tests":[],"coverage_delta":[],"lint_typecheck_build":[],"security_scanners":[],"dependency_audit":[],"secrets_scan":[],"mutation_testing":[]},"swarm_artifacts":{"evidence_bundles":[],"knowledge_hits":[],"phase_state":[],"metrics":[]},"risk_triggers":[]}
Context pack rules
Diff-only review is allowed for quick orientation, but not enough to confirm nontrivial findings.
For every changed production file, identify at least one caller, consumer, import path, route entrypoint, or reason none exists.
If .swarm/repo-graph.json exists, use it to seed impact cones.
If no repo graph exists, build a shallow impact cone using imports, exports, symbol search, route registration, CLI registration, or test references.
Pull in relevant .swarm/evidence/, .swarm/state, .swarm/knowledge, or hive/project knowledge entries when present.
Historical knowledge may guide candidate generation but cannot confirm a finding by itself.
Mark stale, quarantined, or cross-project knowledge as advisory until independently verified in this repo.
Review Finding Persistence
Do not rely on conversation context to preserve review findings. Create a run
artifact under .swarm/pr-review/<run_id>/findings.jsonl when file writes are
allowed, or under .swarm/evidence/pr-review-<run_id>-findings.jsonl when the
review already uses the evidence tree.
Each persisted finding record must include at least:
{"finding_id":"F-001","status":"PENDING","file_line":"src/file.ts:123","evidence":"quote, command output, lane id, or reviewer rationale","next_action":"route_to_reviewer"}
Minimum field contract:
finding_id: stable ID from the candidate/reviewer/critic ledger.
status: one of PENDING, CONFIRMED, DISPROVED, or PRE_EXISTING.
file_line: exact file:line reference, or N/A with reason when the
finding is cross-file or artifact-only.
evidence: compact source-backed proof, including lane/reviewer/critic IDs or
command output references when available.
next_action: the next required action, such as route_to_reviewer,
route_to_critic, report, suppress_with_reason, or handoff_to_feedback.
Persist after every major validation boundary:
Post-explorer: after Phase 3/4 candidate parsing and before reviewer
dispatch, write all candidates as PENDING with their lane provenance.
Post-reviewer: after Phase 6 reviewer validation, update each reviewed
record to CONFIRMED, DISPROVED, PRE_EXISTING, or keep PENDING with a
concrete next_action if more evidence is required.
Post-critic: after Phase 8 critic challenge, update final status,
severity/action notes in evidence, and final reporting or handoff action.
Resume/reload procedure:
Before continuing any compacted or resumed review, read the latest
findings.jsonl artifact and reconstruct the candidate/reviewer/critic
ledger from disk before dispatching more lanes.
If the artifact is missing but a review context says prior lanes ran, stop and
surface the missing artifact as a coverage gap instead of reclassifying from
memory.
Append new records rather than overwriting history unless the artifact format
explicitly tracks revisions; latest record for a finding_id wins during
reload.
Tests are claims. A passing or added test does not prove the obligation unless the reviewer inspects the assertion strength and relevant code path.
Quantitative claim verification
PR body numerical claims (test counts, coverage percentages, assertion counts, performance benchmarks) are obligations, not proof. For each quantitative claim:
Extract the claim and its source (PR body, comment, commit message).
Verify against actual tool output or CI artifacts when available.
If the claim cannot be independently verified, mark the obligation UNVERIFIABLE with reason.
If the claim is disproved by evidence, create a finding linking the discrepancy.
Common patterns to verify:
"N tests pass" → count actual test results from CI logs or test runner output
"N% coverage" → compare against coverage report
"No regressions" → verify against test runner failure count
Phase 2: Deterministic Signal Ingestion
Ingest deterministic signals as candidate generators. They are never final findings.
Use available local artifacts first. Run safe read-only or standard project validation commands only when appropriate for the environment.
Confirm PR-introducedness before reporting as a PR blocker.
Confirm that a framework, schema, middleware, caller guard, or test isolation rule does not already mitigate it.
Do not report scanner output verbatim without reviewer validation.
Redact secrets; never paste raw credentials into the final output.
Phase 3: Parallel Base Explorer Lanes
Launch all base lanes with dispatch_lanes_async when available. Pass the six lane specs together, set max_concurrent to 6, record the returned batch_id, and continue only non-dependent architect work: refine the obligation ledger, inspect PR metadata, prepare micro-lane trigger checks, and run deterministic read-only local tools. Do not synthesize findings from running lanes. Keep each lane prompt compact: send the shared review context (PR diff, obligation ledger, scope) ONCE via the common_prompt field, or have lanes read it from a file by absolute path, instead of inlining the same large blob into all six prompts — oversized inline prompts produce malformed or truncated tool-call JSON and force clumsy file workarounds.
Incremental collection: While base lanes are running, poll with collect_lane_results (without wait or wait: false) to check progress and process settled lanes as they complete — call retrieve_lane_output for full text when output_ref is present, then extract candidates via parse_lane_candidates, update the candidate ledger, validate output quality — while continuing independent architect work (obligation refinement, micro-lane trigger checks, local reads) between polls. Only use wait: true if lanes are still pending and no more independent work remains.
Before Phase 4 or synthesis, all base lanes must be settled. dispatch_lanes_async accepts a maximum of 8 lanes per call; base lanes (6) and micro-lanes (Phase 4) are dispatched in separate calls by design. Do not let one lane's conclusions bias another lane.
COVERAGE GATE — zero tolerance for unclosed gaps. After collect_lane_results, verify every lane produced validated output. Two failure modes exist:
Mode A (empty output): Lane returns 0 chars, status: cancelled, output_digest matches SHA-256 of empty string (e3b0c442...b855).
Mode B (intermediate reasoning only): Lane reports status: completed with non-empty output, but the output is preliminary reasoning ("Now let me check...") with zero [CANDIDATE] rows. The output_digest does NOT match the empty-string hash. parse_lane_candidates returns 0 candidates. This mode is MORE dangerous — the lane appears successful but produced no findings.
For ANY lane that failed (either mode):
Retry (max 2 attempts) with materially different parameters — different session, different prompt decomposition, or blocking dispatch_lanes.
If retries fail, deploy an equivalent alternative and verify equivalence: same agent type, same prompt, same scope, same isolation. Fallback order is explicit: retry or re-collect dispatch_lanes_async first, use blocking dispatch_lanes when async dispatch or collection cannot close coverage, then use the Task tool as the last-resort equivalent dispatch mechanism when lane tools do not work. State the Task fallback equivalence verification explicitly. Task is not an early-poll or empty-partial-output fallback; use retrieve_lane_output to inspect the full artifact before declaring equivalence or failure.
If no equivalent alternative can be verified, STOP and surface the lane failure to the user as BLOCKED with the lane id, scope, failure mode, retry attempts, and why equivalence could not be proven. Do not present partial findings, do not issue a review verdict, and do not synthesize from successful lanes. A low-quality partial review is worse than no review.
Candidate extraction via parser
After collect_lane_results returns for base lanes, process each lane result
that carries an output_ref. The orchestrator MUST use the candidate parser
rather than preview-text extraction:
For each output_ref (or batched), call parse_lane_candidates (or the
internal parseAndPersist module function) with output_ref and producer
flags; the parser auto-detects the format family per row. The parser reads
the full artifact from disk (no preview truncation issue) and returns
structured ParseResultWithSidecar records.
Filter the returned candidates[] array by producer: "swarm-pr-review" and
the relevant row_format_family (e.g., base_explorer for base lanes,
micro_lane for micro-lanes). Filtering happens on the parsed results, NOT
on the tool input.
Group the filtered candidates into reviewer-sized chunks:
by file area (group by the directory or module of the file_line field),
by category (group by the category field),
by count (target max 50 candidates per chunk; smaller chunks are fine).
Dispatch reviewer lanes (one per chunk) with bounded in-context candidate
lists. Each reviewer lane receives only the candidates from its assigned
chunk.
If a lane has output_degraded: true, transcript_incomplete: true, or no usable output_ref, apply the COVERAGE GATE from Phase 3: retry (max 2) with materially different parameters, then use blocking dispatch_lanes or the Task tool as verified-equivalent fallbacks when lane tools do not work. If the gap cannot be closed, stop and surface the lane failure to the user as BLOCKED. Do not mark affected candidates UNVERIFIED to proceed past the gap. Never infer candidate absence from a preview.
After candidate parsing and before reviewer dispatch, persist the post-explorer
candidate ledger using the Review Finding Persistence contract. This is the
durable recovery point for context compaction before Phase 6.
Fallback convention: If the parser is unavailable, the explorer MAY emit
[CANDIDATE] rows in the lane output as a fallback convention (see the
Explorer Prompt Template at the end of this skill), but the orchestrator
SHOULD use the parser as the primary extraction mechanism.
lane id uniqueness for parallel dispatches: When re-dispatching failed or
re-running explorer lanes, every dispatch_lanes_async or dispatch_lanes
lane id MUST be unique within that dispatch batch and should include lane and
attempt suffixes (e.g., pr_review_explore_lane1_attempt2). Never reuse an id
in the same batch unless intentionally replacing that exact lane before dispatch.
Explorers optimize for recall. Over-reporting is expected. Explorers produce candidates only.
The six lanes are a fixed check-type partition (correctness / security / deps / docs / tests / performance), not an area partition: the count is intentionally constant — every PR needs all six review dimensions — and the lanes deliberately overlap by file, each receiving the same diff via common_prompt and viewing it through a different lens. This is the deliberate exception to surface-scaled fan-out: the base wave is a fixed six by design, never collapsed or expanded with the size of the change. Coverage is guaranteed by the six dimensions each reading the whole diff, not by partitioning files across lanes — so the disjoint-partition rule that governs area-split fan-outs does not apply to these check-type lanes.
The parser normalizes this into a structured candidates[] array. If the
parser is unavailable, the explorer MAY emit the [CANDIDATE] row format
directly in the lane output as a fallback convention.
Explorers must not use CONFIRMED, DISPROVED, or PRE_EXISTING.
Phase 4: Triggered Swarm Plugin Micro-Lanes
After base lanes are settled, inspect the context pack risk triggers. Launch focused micro-lanes for triggered categories only, using dispatch_lanes_async again when more than one read-only micro-lane is needed (dispatch_lanes_async accepts max 8 lanes per call — micro-lanes are dispatched in a separate batch from base lanes). Use the same incremental collection pattern: poll with collect_lane_results (without wait) to process settled micro-lanes while continuing independent work, falling back to wait: true only when no independent work remains. All micro-lanes must be settled before reviewer classification. Do not launch irrelevant micro-lanes.
Apply the same parser-based extraction to micro-lanes: call parse_lane_candidates on each micro-lane output_ref (filter the returned candidates[] array by row_format_family === "micro_lane" after parsing). Apply the COVERAGE GATE from Phase 3 to micro-lanes: degraded, incomplete, or candidate-less lane artifacts are coverage gaps that must be closed by retry, blocking dispatch_lanes, or Task-tool dispatch as a verified-equivalent fallback when lane tools do not work. If the gap cannot be closed, stop and surface it to the user as BLOCKED before reviewer classification — never treat it as clean negative evidence and never proceed with a degraded review.
Each micro-lane receives:
exact files and hunks in scope,
related obligations,
impact cone entries,
relevant deterministic signals,
related historical knowledge with quarantine/staleness status,
expected invariants,
structured candidate output (parser-extracted). If the parser is unavailable,
the micro-lane MAY emit [CANDIDATE] rows as a fallback convention.
Swarm plugin risk trigger map
Trigger in diff or context pack
Launch micro-lane
Invariants to check
agents, prompts, templates, prompt interpolation, role text
Architect prompt integrity
no scope escape, no system prompt leakage, safe {{variable}} interpolation, untrusted text isolated from instructions
council, verdict, quorum, veto, synthesis
Council orchestration
quorum math correct, veto enforced, evidence not lost, dissent preserved, no explorer result treated as final
Use Swarm-native agents and artifacts when available. If exact agent names are unavailable, route the same task to the closest equivalent reviewer/critic role.
confirmed/borderline correctness, security, state, schema, or config findings
propose or run falsification probes and regression tests
prm_scorer
long or contentious reviews
score whether review trajectory is drifting toward unsupported speculation
.swarm/repo-graph.json
all nontrivial code changes
build impact cones and sibling-pattern checks
.swarm/evidence/
schema, phase, state, council, and guardrail changes
verify evidence compatibility and serialized provenance
/swarm metrics or stored metrics
after synthesis
record review quality and recurring false positives
Verifier output is advisory until incorporated by the independent reviewer or critic.
Phase 6: Independent Reviewer Confirmation
Route candidates to reviewer subagents. The orchestrator routes candidates
in bounded chunks produced by the parser-based extraction in Phase 3-4. Each
reviewer lane receives a bounded list of candidates from a single chunk — by
file area, category, or count — not the full candidate set. The reviewer must
re-read the candidate's file:line evidence and relevant context pack entries
directly.
Noise budget and universal validation
Before reviewer dispatch, the orchestrator may suppress candidates that are ALL of:
purely stylistic without correctness, security, test, maintainability, or user-impact implications,
exact duplicates of a candidate already queued for validation,
explorer-stated confidence=LOW with zero structural evidence (no file:line, no code path, no invariant reference).
Every suppressed candidate must appear in the final report under "Suppressed Candidates" with the reason. Suppression without disclosure is a hard rule violation.
All remaining candidates — regardless of severity — must be routed to independent reviewer validation. Severity alone does not determine validation eligibility; it determines routing priority. A LOW-severity candidate with file:line evidence and a specific code path gets the same reviewer attention as a HIGH-severity candidate.
Candidates not routed to reviewers must be listed as UNVERIFIED with reason in the validation provenance. Do not silently drop them.
Reviewer required checks
For each candidate, the reviewer must determine:
exact file:line evidence,
whether the issue is introduced by this PR or pre-existing,
DISPROVED findings must include the reason. PRE_EXISTING findings must include the base-branch evidence if available.
After reviewer lanes settle, persist the post-reviewer finding ledger before
critic routing or synthesis. The artifact must preserve CONFIRMED,
DISPROVED, PRE_EXISTING, and still-PENDING records with reviewer IDs and
next actions.
Phase 7: Falsification Probe Requirement
Each confirmed nontrivial finding must include at least one falsification artifact:
runnable failing command,
proposed regression test,
mutation that current tests fail to kill,
static-analysis trace,
minimal execution path,
exact reason no runtime probe is available.
Nontrivial means any finding that affects correctness, security, state transitions, write authority, git safety, config, schema/evidence integrity, model/tool permissions, external fetches, persistence, or user-visible behavior.
A finding may still be reported without a runnable command if it is structurally proven, but the report must state why a runtime probe was not available.
Phase 8: Critic Challenge
Route every reviewer-confirmed HIGH or CRITICAL finding to a critic. Also route borderline MEDIUM findings when they involve security, state machines, write authority, evidence integrity, model/tool permissions, git safety, or config ratchets.
The critic must challenge:
severity inflation,
weak or incomplete evidence,
missing mitigating context,
false reachability assumptions,
framework or middleware defaults,
schema validation gates,
state-machine constraints,
feature flags or dead code,
pre-existing status,
non-actionable or unsafe fix recommendations,
sibling-file gaps,
whether multiple comments should be grouped into one root cause.
The [CRITIC] row in the format above is mandatory contract, not advisory output. A critic response that does not end with that exact row format is treated as a planning preamble, not a verdict, and must be re-dispatched. Do not proceed past Phase 8 join barrier until each dispatched critic lane has produced a parseable [CRITIC] row.
Re-dispatch trigger: when a critic lane response is missing the verdict row, the orchestrator must automatically re-dispatch that lane with the explicit instruction: "Your final line MUST be exactly the Phase 8 contract row: [CRITIC] | finding_id | UPHELD/DOWNGRADED/DISPROVED/NEEDS_MORE_EVIDENCE | final_severity | reason | required_report_change. A response without that exact row will be treated as a planning message and re-dispatched." Do not synthesize findings from the planning preamble; only from the re-dispatched verdict.
COVERAGE GATE alignment: Critic lane failures follow the same COVERAGE GATE as explorer lanes: retry (max 2 attempts) with materially different parameters. If retries fail, deploy a verified equivalent alternative (same agent type, same prompt, same scope, same isolation), including Task-tool dispatch as the final fallback when lane tools do not work. If no equivalent can be verified, stop and surface the critic-lane failure to the user as BLOCKED — do NOT mark findings UNVERIFIED or continue past the gap. The orchestrator NEVER fabricates a critic verdict by parsing prose, by tolerating a planning preamble, by presenting partial findings, or by silently accepting reduced coverage.
Refuted findings become DISPROVED or ADVISORY, depending on critic rationale. Downgrades must be listed in the final validation provenance.
After critic lanes settle, persist the post-critic finding ledger before final
synthesis. This artifact is the source of truth for resumed reporting and for
any later swarm-pr-feedback handoff.
Runtime-Aware False-Positive Guard Checklist
Before confirming any finding, the reviewer and critic must check all that apply:
Schema validation gate: does schema validation reject malformed input before the flagged line?
Middleware interception: does middleware handle the request or command before the flagged path?
Framework default mitigation: does the framework inherently prevent this class of issue?
Caller context correctness: who invokes this code, and can untrusted input reach it?
Execution reachability: is the path reachable, or behind a feature flag, dead branch, build-only path, or commented-out code?
State-machine constraints: do ordering rules, locks, mutexes, phase gates, or transition guards prevent the state?
Permission boundary: does role/tool mapping prevent the operation?
Data lifetime: is the flagged state persisted, serialized, logged, or only transient?
Cross-platform behavior: does Windows/macOS/Linux path or shell behavior change the result?
Test environment mismatch: is the finding only true under a mock or fixture that cannot occur in production?
If a mitigation applies and was not accounted for, downgrade to ADVISORY, UNVERIFIED, or DISPROVED.
Phase 9: Synthesis, Grouping, and Noise Budget
Before final output:
group duplicate candidates by root cause,
report one finding per root cause,
attach all affected file:line references under that finding,
separate ship blockers from advisory notes,
suppress pure style/nit findings unless they indicate correctness, security, test, maintainability, or user-impact risk,
distinguish PR-introduced from pre-existing,
distinguish confirmed from plausible-but-unverified,
include disproved agent/tool claims,
keep final comments actionable.
Finding ID format
F-001 | severity | category | root cause | affected file:line refs | reviewer | critic status
Suggested final grouping
Ship blockers,
Important non-blockers,
Test / coverage gaps,
Pre-existing issues,
Unverified plausible risks,
Disproved candidates / false positives,
Clean lane summary.
Phase 10: Metrics and Knowledge Writeback
At the end of the review, record review quality metrics when Swarm metrics or local evidence storage is available.
Record:
raw candidates by base lane,
raw candidates by micro-lane,
deterministic tool candidates,
reviewer-confirmed findings,
reviewer-disproved findings,
reviewer-unverified findings,
critic-upheld findings,
critic-downgraded findings,
critic-disproved findings,
final reported findings,
suppressed non-actionable candidates,
recurring false-positive patterns,
commands or probes used,
token/time cost if available,
accepted/fixed findings when known.
Knowledge writeback rules:
Write back only validated true positives or validated false-positive patterns.
Include file patterns, invariant, evidence, and why it was confirmed/disproved.
Mark repo-specific lessons as project-tier unless there is strong evidence they generalize.
Never promote quarantined or unvalidated knowledge to hive-tier.
Never store secrets, private tokens, or raw sensitive logs.
Phase 11: Post-Fix Re-verification
When the PR author pushes fixes after a review, perform a targeted re-verification before updating the verdict.
Re-verification scope
Only re-verify findings the author claims to have fixed. Do not re-run the full review pipeline.
Re-verification steps
For each finding the author claims fixed:
a. Read the changed file(s) from the updated branch at the specific lines referenced in the original finding.
b. Verify the fix addresses the root cause, not just the symptom.
c. Check that the fix does not introduce a new issue in the same area.
Run CI checks on the updated branch to confirm no regressions.
For findings the author did not address, carry forward the original finding with unchanged status.
FIXED: the root cause is resolved and no new issue introduced.
PARTIALLY_FIXED: the root cause is partially addressed or a residual concern remains.
NOT_FIXED: the root cause persists unchanged.
NEW_ISSUE: the fix introduced a new problem at the same location.
Update the verdict only after re-verifying all previously blocking findings.
Dry-Run: Parser-Based Candidate Extraction
This section demonstrates the new parser-based extraction path end-to-end
using synthetic data. It is concrete enough to implement the same pattern in
another skill.
Scenario
A PR review has dispatched six base explorer lanes via dispatch_lanes_async.
The batch completed and collect_lane_results returned:
The parser returns a ParseResultWithSidecar. On success, error and error_code are absent:
{"candidates":[{"record_type":"candidate","row_format_family":"base_explorer","row_format_version":1,"record_version":{"major":1,"minor":0},"source_output_ref":".swarm/lane-results/batch-a1b2c3/lane-1/out-abc123.json","source_batch_id":"B-2025-06-22-001","source_lane_id":"explorer-1","source_agent":"paid_explorer","source_digest":"sha256:abc123def456...","extracted_from_partial_source":false,"sessionId":"ses_01HXYZ...","parentSessionId":"ses_01HABC...","producer":"swarm-pr-review","candidate_id":"C-001","lane":"Lane 1: Correctness and edge cases","micro_lane":null,"severity":"HIGH","category":"null-safety","file_line":"src/utils/cache.ts:142","claim":"Uncached getter may return undefined on cold start","evidence_summary":"The `getCached` function returns `cache[key]` without a fallback when the cache is empty.","impact_context":"Downstream callers in `src/handlers/*.ts` expect a defined value and call `.toString()` directly.","invariant_violated":null,"confidence":"HIGH"},{"record_type":"candidate","row_format_family":"base_explorer","row_format_version":1,"record_version":{"major":1,"minor":0},"source_output_ref":".swarm/lane-results/batch-a1b2c3/lane-1/out-abc123.json","source_batch_id":"B-2025-06-22-001","source_lane_id":"explorer-1","source_agent":"paid_explorer","source_digest":"sha256:abc123def456...","extracted_from_partial_source":false,"sessionId":"ses_01HXYZ...","parentSessionId":"ses_01HABC...","producer":"swarm-pr-review","candidate_id":"C-002","lane":"Lane 1: Correctness and edge cases","micro_lane":null,"severity":"MEDIUM","category":"async-ordering","file_line":"src/services/queue.ts:88","claim":"Race between `drain` and `processNext` may drop items","evidence_summary":"`drain` sets `active = false` before awaiting `processNext`, which also checks `active`.","impact_context":"Items submitted during the drain window are silently dropped.","invariant_violated":null,"confidence":"MEDIUM"}],"invocation_envelope":{"record_type":"invocation","source_output_ref":".swarm/lane-results/batch-a1b2c3/lane-1/out-abc123.json","source_batch_id":"B-2025-06-22-001","source_lane_id":"explorer-1","source_agent":"paid_explorer","source_digest":"sha256:abc123def456...","row_format_version":1,"record_version":{"major":1,"minor":0},"sessionId":"ses_01HXYZ...","parentSessionId":"ses_01HABC...","producer":"swarm-pr-review","produced_at":"2025-06-22T14:30:00.000Z","format_families_detected":["base_explorer"],"candidate_count":2,"parse_errors":2,"malformed_rows":0},"diagnostics":{"candidate_count":2,"parse_errors":2,"parse_error_details":[{"row_index":0,"field":"row","message":"Both format-family discriminators present; defaulting to base_explorer"},{"row_index":1,"field":"row","message":"Both format-family discriminators present; defaulting to base_explorer"}],"malformed_rows":0,"duplicate_id_count":0,"duplicate_id_warnings":[],"degraded_source_count":0,"incomplete_source_count":0,"format_families_detected":["base_explorer"]}}
Note: parse_errors: 2 reflects FR-017/SC-017 position-based detection: when a [CANDIDATE] row has both evidence_summary and impact_context populated, the parser emits a parse_error_details entry per row with field: "row" and message: "Both format-family discriminators present; defaulting to base_explorer". This is documented behavior, not a parser bug. To get parse_errors: 0 with the row format, leave one of the two fields empty; to silence the warning entirely, emit structured JSON candidate records.
On refusal (e.g. output_ref does not exist), error and error_code are present; candidates is []; invocation_envelope and diagnostics are populated with empty fields for traceability:
{"error":"Artifact reference not found in store","error_code":"ref-not-found","candidates":[],"invocation_envelope":{"record_type":"invocation","source_output_ref":".swarm/lane-results/batch-a1b2c3/lane-1/missing.json","source_batch_id":"","source_lane_id":"","source_agent":"","source_digest":"","row_format_version":1,"record_version":{"major":1,"minor":0},"produced_at":"2025-06-22T14:30:00.000Z","format_families_detected":[],"candidate_count":0,"parse_errors":0,"malformed_rows":0},"diagnostics":{"candidate_count":0,"parse_errors":0,"parse_error_details":[],"malformed_rows":0,"duplicate_id_count":0,"duplicate_id_warnings":[],"degraded_source_count":0,"incomplete_source_count":0,"format_families_detected":[]}}
Step 3 — Filter and group
The orchestrator filters the returned candidates[] array by producer: "swarm-pr-review" and row_format_family (e.g. base_explorer or micro_lane), then groups
the candidates. In this synthetic example, the two candidates above are grouped
by file area:
Chunk A — src/utils/ (1 candidate): C-001
Chunk B — src/services/ (1 candidate): C-002
If there were more candidates, the orchestrator would also group by category
(e.g., null-safety, async-ordering) and cap each chunk at 50 candidates.
Step 4 — Dispatch reviewer lanes
The orchestrator dispatches one reviewer lane per chunk:
You are the independent reviewer. Validate only the candidates assigned below.
Do not search for new issues except where needed to validate reachability or
mitigation. Do not trust explorer severity.
Context pack summary:
- scope: ...
- obligations: ...
- impact cone: ...
- deterministic signals: ...
- relevant Swarm artifacts / knowledge: ...
- base_ref: <commit SHA of base branch>
- head_ref: <commit SHA of PR head branch>
Candidates (Chunk A — src/utils/):
- C-001 | HIGH | null-safety | src/utils/cache.ts:142 | Uncached getter may return undefined on cold start
For each candidate, return:
[REVIEWED] | candidate_id | CONFIRMED/DISPROVED/UNVERIFIED/PRE_EXISTING | evidence_type | final_severity | introduced_by_pr | file:line | rationale | falsification_probe | reviewer_id
You must check caller context, reachability, schema/middleware/framework mitigations, state-machine constraints, test coverage, PR-introducedness, and severity.
IMPORTANT: If a finding claims behavior is "new" or "introduced by the PR", you MUST read the equivalent code on the base branch (git show <base_ref>:<file>) to verify it was not present before. A reviewer claim of "this is new" is invalid without base-branch evidence. Do not compare the new code to an idealized baseline — compare it to what actually existed on the base branch at the time of the PR.
Key invariants
The parser reads the full artifact, not a preview. Truncation in the
dispatch_lanes preview does not affect candidate extraction.
The orchestrator never classifies candidates — it only filters, groups, and
routes them.
Each reviewer receives a bounded chunk. A chunk with more than 50 candidates
is split before dispatch.
The invocation_envelope in the parser response provides audit provenance
for every extracted candidate.
Council Mode Workflow
Council mode is opt-in only and adversarial.
When triggered:
Build the same context pack as default mode.
Launch all council agents with one dispatch_lanes_async call when available; continue independent context preparation while they run, polling with collect_lane_results (without wait) to process settled agents incrementally. Use wait: true only when no independent work remains and agents are still pending. All agents must be settled before reviewer classification. Fall back to blocking dispatch_lanes when async launch is unavailable.
Each council agent assumes all work is wrong until code evidence proves otherwise.
Each agent hunts within its lane only.
Agents return evidence states only: EVIDENCE_FOUND, SUSPICIOUS, or CLEAN.
Agents must not return CONFIRMED, DISPROVED, or final severity.
The independent reviewer then classifies every council candidate as CONFIRMED, DISPROVED, UNVERIFIED, or PRE_EXISTING.
Apply critic challenge to reviewer-confirmed HIGH/CRITICAL or borderline findings.
Final synthesis distinguishes real blockers, real low-severity issues, accepted caveats, disproved council claims, and follow-up quality work.
Default council lanes:
correctness and edge cases,
security and trust boundaries,
dependency and deployment safety,
docs and intent-vs-actual,
tests and falsifiability,
performance and architecture when risk justifies it.
Council prompt requirements:
branch and commit range,
context pack summary,
files owned by that lane,
relevant impact cone,
explicit checklist,
strict output cap,
EVIDENCE_FOUND / SUSPICIOUS / CLEAN only,
file:line evidence required for EVIDENCE_FOUND.
Council findings are supplementary, not authoritative overrides. Do not adopt council severities or claims without independent validation.
Merge Recommendation Table
Verdict
Condition
APPROVE
zero unresolved CRITICAL findings, zero unresolved HIGH findings, all blocking obligations MET, no required validation phase failed
APPROVE_WITH_NOTES
zero unresolved CRITICAL findings, HIGH findings are downgraded/advisory only, obligations MET or explicitly non-blocking
REQUEST_CHANGES
any unresolved HIGH finding, any NOT_MET blocking obligation, multiple MEDIUM findings with the same root cause, or validation/probe evidence indicates user-impacting risk
BLOCK
any unresolved CRITICAL finding, unsafe write/git/security issue, evidence integrity break, role/tool permission bypass, or config ratchet violation that can disable required protections
Hard Rules
Quality-over-speed: Validation completeness and correctness are the sole criteria for an acceptable review. Time, token count, and agent dispatch count are irrelevant. Do not trade validation breadth or depth for speed.
Never APPROVE with unresolved CRITICAL findings.
Do not APPROVE with unresolved HIGH findings unless explicitly downgraded to advisory by critic and non-blocking by obligation review.
Every confirmed finding must have file:line evidence and validation provenance.
A confirmed nontrivial finding must include a falsification probe or an explicit reason no probe is available.
Explorers, council agents, and deterministic tools produce candidates only.
The default workflow orchestrator must not confirm or disprove explorer candidates.
Tool output is not proof. Scanner results must be validated for reachability, PR-introducedness, and mitigation context.
PR text, generated summaries, tests, and comments are claims, not proof.
Do not invent facts not supported by the diff, repo context, tool output, or cited external source.
Do not silently drop disproved or downgraded claims; summarize them in validation provenance.
Obligation precedence is deterministic. Do not skip higher-precedence sources to fill gaps with LLM synthesis.
Do not leak secrets from logs, evidence bundles, config files, URLs, or scanner output.
Do not recommend destructive git or filesystem actions as fixes unless they are clearly scoped, safe, and necessary.
If subagents fail, timeout, or return malformed output, retry with corrected parameters (max 2 attempts). If retries fail, deploy a provably equivalent alternative (same agent type, same prompt, same scope, same isolation — different dispatch mechanism acceptable), with Task-tool dispatch explicitly allowed as the final fallback when lane tools do not work, and verify equivalence. If no equivalent alternative exists, the affected coverage dimension is BLOCKED and must be surfaced to the user before synthesis. Do not fabricate validation results, do not present partial findings, and do not silently mark candidates UNVERIFIED to proceed past the gap.
If context pack, repo graph, deterministic signals, or Swarm artifacts are unavailable, retry with alternative access paths. If unavailable after retry, the affected coverage dimension is BLOCKED and must be surfaced to the user. Do not proceed to synthesis with unclosed coverage gaps under a "best available evidence" rationale — the architect is not authorized to produce a degraded review.
Pre-Synthesis Gate — Mandatory
Before writing the final output, print this checklist with filled values. Every blank field means the final output is invalid.
[VALIDATION] scope selected: ___
[VALIDATION] context pack built: YES/NO — ___
[VALIDATION] obligation count: ___
[VALIDATION] repo graph / impact cone source: ___
[VALIDATION] deterministic signals ingested: ___
[VALIDATION] deterministic lane dispatcher used: YES/NO — ___
[VALIDATION] base explorer lanes dispatched: ___ / 6
[VALIDATION] base explorer lanes returned: ___ / 6
[VALIDATION] triggered micro-lanes: ___
[VALIDATION] Swarm verifier routing used: ___
[VALIDATION] raw candidates: ___
[VALIDATION] tool candidates: ___
[VALIDATION] reviewer dispatched: ___ (agent type, task description)
[VALIDATION] reviewer returned: ___ (APPROVED / REJECTED / CONCERNS — copy verdict text)
[VALIDATION] findings confirmed by reviewer: ___
[VALIDATION] findings rejected by reviewer as false positive: ___
[VALIDATION] findings marked PRE_EXISTING: ___
[VALIDATION] findings left UNVERIFIED: ___
[VALIDATION] findings escalated to critic: ___
[VALIDATION] critic dispatched: ___ OR "SKIPPED — no reviewer-confirmed HIGH/CRITICAL or borderline findings"
[VALIDATION] critic returned: ___ OR "N/A"
[VALIDATION] findings upheld by critic: ___
[VALIDATION] findings downgraded by critic: ___
[VALIDATION] findings disproved by critic: ___
[VALIDATION] falsification probes included: ___
[VALIDATION] grouped root-cause findings: ___
[VALIDATION] metrics / knowledge writeback: ___
[VALIDATION] all explorers verified to diff against PR branch, not HEAD: YES/NO
[VALIDATION] noise-filter suppressed candidates: ___ (count, each with reason in final report)
[VALIDATION] all non-suppressed candidates routed to reviewer: YES/NO
If the reviewer returned REJECTED or CONCERNS, route the issue back to implementation context or mark the candidate invalid with reason. Do not silently downgrade a rejection.
COVERAGE GATE CONDITION: If ANY validation dimension shows incomplete coverage (lanes that failed and were not closed by retry or verified equivalent alternative, CI that did not run, tools that were unavailable after retry), the Pre-Synthesis Gate FAILS. Do not proceed to final output. Surface the unclosed gaps to the user as BLOCKED with exact failing dimensions and retry/equivalence evidence. Do not include partial findings from successful dimensions, do not issue a review verdict, and do not silently accept reduced coverage.
Final Output Format
Produce the final review in this order:
PR intent
Summarize the obligations and user-visible intent.
Implementation summary
Summarize what changed, including major files, public APIs, schemas, configs, tests, and Swarm artifacts.
Intended vs actual mapping
Obligation
Source
Actual evidence
Status
Linked finding
Use MET, PARTIALLY_MET, NOT_MET, or UNVERIFIABLE.
Validation provenance
Include:
context pack limitations,
explorer lanes launched and returned,
micro-lanes triggered,
deterministic signals ingested,
reviewer identity / role for each finding,
critic result for each escalated finding,
findings DISPROVED by reviewer with reason,
findings DOWNGRADED by critic with reason,
findings left UNVERIFIED with reason.
If zero findings, explicitly state:
No confirmed findings — all validated lanes CLEAN.
Only include if useful and clearly labeled as unverified.
Test / coverage gaps
Focus on missing tests that would catch real risks, not generic coverage requests.
Disproved candidates and false positives
List concise reasons for notable false positives from explorers, tools, council agents, or reviewers.
Verdict
Use one of:
APPROVE
APPROVE_WITH_NOTES
REQUEST_CHANGES
BLOCK
Merge recommendation
Explain the recommendation in one short paragraph and list required actions before merge if applicable.
Feedback handoff
When the review produced actionable validated findings or operational blockers,
include:
the handoff artifact path,
the preserved finding IDs and provenance that swarm-pr-feedback must carry
forward,
and an explicit question asking whether to continue into
swarm-pr-feedback.
Use this exact continuation prompt format:
/swarm pr-feedback <PR_URL> continue from .swarm/pr-review/<run_id>/feedback-handoff.md
Reviewer Prompt Template
Use this template when dispatching reviewer subagents:
You are the independent reviewer. Validate only the candidates assigned below.
Do not search for new issues except where needed to validate reachability or mitigation.
Do not trust explorer severity.
Context pack summary:
- scope: ...
- obligations: ...
- impact cone: ...
- deterministic signals: ...
- relevant Swarm artifacts / knowledge: ...
- base_ref: <commit SHA of base branch>
- head_ref: <commit SHA of PR head branch>
Candidates:
- ...
For each candidate, return:
[REVIEWED] | candidate_id | CONFIRMED/DISPROVED/UNVERIFIED/PRE_EXISTING | evidence_type | final_severity | introduced_by_pr | file:line | rationale | falsification_probe | reviewer_id
You must check caller context, reachability, schema/middleware/framework mitigations, state-machine constraints, test coverage, PR-introducedness, and severity.
IMPORTANT: If a finding claims behavior is "new" or "introduced by the PR", you MUST read the equivalent code on the base branch (git show <base_ref>:<file>) to verify it was not present before. A reviewer claim of "this is new" is invalid without base-branch evidence. Do not compare the new code to an idealized baseline — compare it to what actually existed on the base branch at the time of the PR.
Critic Prompt Template
Use this template when dispatching critic subagents:
You are the adversarial critic. Challenge only reviewer-confirmed findings assigned below.
Your goal is to reduce false positives, severity inflation, and non-actionable reports.
For each finding, challenge:
- whether evidence proves the claim,
- whether the path is reachable,
- whether mitigations apply,
- whether severity is inflated,
- whether it is PR-introduced,
- whether suggested fixes are safe/actionable,
- whether related files were missed,
- whether multiple findings should be grouped.
Return:
[CRITIC] | finding_id | UPHELD/DOWNGRADED/DISPROVED/NEEDS_MORE_EVIDENCE | final_severity | reason | required_report_change
REQUIRED FINAL LINE — your final line MUST be exactly the row above (no variations, no labeled fields, no placeholders):
[CRITIC] | finding_id | UPHELD/DOWNGRADED/DISPROVED/NEEDS_MORE_EVIDENCE | final_severity | reason | required_report_change
A response without this exact row is treated as a planning preamble and re-dispatched. Do not output only a planning or investigation message.
Explorer Prompt Template
Use this template when dispatching base explorer or micro-lane agents:
You are an explorer. Optimize for recall, not final judgment.
Return candidates only. Do not use CONFIRMED, DISPROVED, or PRE_EXISTING.
Lane:
Scope:
Obligations:
Changed files/hunks:
Impact cone:
Relevant deterministic signals:
Relevant Swarm artifacts / knowledge:
Checklist:
You must inspect or mark unavailable:
1. changed hunk,
2. caller/consumer,
3. callee/dependency,
4. sibling implementation or prior pattern,
5. nearest test or missing-test location,
6. deterministic signals,
7. Swarm artifacts/knowledge.
Return:
[CANDIDATE] | candidate_id | lane | severity | category | file:line | claim | evidence_summary | impact_context | confidence
The orchestrator extracts candidates from the full lane artifact via
parse_lane_candidates as the primary mechanism. The [CANDIDATE] row
format above is a fallback convention for environments where the parser is
unavailable. Explorers should still emit structured records regardless of
whether the parser is present.
