review-swarm

What the source does

• FilesystemNone observedNo reads or writes in the source
• NetworkNone observedNo outbound calls in the source
• ShellNone observedNo commands run in the source
• DependenciesPinnedNothing floats
• SecretsNone foundNo keys in source

Five audit layers

Gates applied: no behavioural pass.

Audit 0.4.1 · source sha 3c36442853dc · 28 Oct 2026Report an issue or request a re-scan

• Publisherdimillian GitHub userOwner of the repository this skill is read from
• Source folderdimillian/skills/review-swarmThe exact folder we audited
• LicenceMITAs the repository states it
• Commit pinned for this verdict3c36442853dcA new audit runs when the source changes
• Repository statusNot archivedLast push 212 days ago
• Sandboxed runNot runSkills are read, not executed; layer L4 is skipped

Its description: Parallel read-only multi-agent review of a current git diff or explicit file scope to find behavioral regressions, security or privacy risks, performance or reliability issues, and contract or test coverage gaps. Use…

---
name: review-swarm
description: "Parallel read-only multi-agent review of a current git diff or explicit file scope to find behavioral regressions, security or privacy risks, performance or reliability issues, and contract or test coverage gaps. Use when the user asks for a review swarm, parallel review, diff review, regression review, security review, or wants high-signal issues plus a prioritized fix path without editing files."
---

# Review Swarm

Review a diff with four read-only sub-agents in parallel, then have the main agent filter, order, and summarize only the issues that matter. This skill is review-only: sub-agents do not edit files, and the main agent does not apply fixes as part of this workflow.

## Step 1: Determine Scope and Intent

Prefer this scope order:

1. Files or paths explicitly named by the user
2. Current git changes
3. An explicit branch, commit, or PR diff requested by the user
4. Most recently modified tracked files, only if the user asked for a review and there is no clearer diff

If there is no clear review scope, stop and say so briefly.

When using git changes, choose the smallest correct diff command:

- unstaged work: `git diff`
- staged work: `git diff --cached`
- mixed staged and unstaged work: review both
- explicit branch or commit comparison: use exactly what the user requested

Before launching reviewers, read the closest local instructions and any relevant project docs for the touched area, such as:

- `AGENTS.md`
- repo workflow docs
- architecture or contract docs for the touched module

Build a short intent packet for the reviewers:

1. What behavior is meant to change
2. What behavior should remain unchanged
3. Any stated or inferred constraints, such as compatibility, rollout, security, or migration expectations

If the user did not state the intent clearly, infer it from the diff and say that the inference may be incomplete.

## Step 2: Launch Four Read-Only Reviewers in Parallel

Launch four sub-agents when the scope is large enough for parallel review to help. For a tiny diff or one very small file, it is acceptable to review locally instead.

For every sub-agent:

- give the same scope and the same intent packet
- state that the sub-agent is read-only
- do not let the sub-agent edit files, run `apply_patch`, stage changes, commit, or perform any other state-mutating action
- ask for concise findings only
- ask for: file and line or symbol, issue, why it matters, recommended follow-up, and confidence
- tell the sub-agent to avoid nits, style preferences, and speculative concerns without concrete impact
- tell the sub-agent to send findings back to the main agent only

Use these four review roles.

### Sub-Agent 1: Intent and Regression Review

Review whether the diff matches the intended behavior change without introducing extra behavior drift.

Check for:

1. Unintended behavior changes outside the stated scope
2. Broken edge cases or fallback paths
3. Contract drift between callers and callees
4. Missing updates to adjacent flows that should change together

This sub-agent is read-only. It must not edit files, apply patches, or make any other workspace changes.

Recommended sub-agent role: `reviewer`

### Sub-Agent 2: Security and Privacy Review

Review the diff for security regressions, privacy risks, and trust-boundary mistakes.

Check for:

1. Missing or weakened authn or authz checks
2. Unsafe input handling, injection risks, or validation gaps
3. Secret, token, or sensitive data exposure
4. Risky defaults, permission expansion, or trust of unverified data

This sub-agent is read-only. It must not edit files, apply patches, or make any other workspace changes.

Recommended sub-agent role: `reviewer`

### Sub-Agent 3: Performance and Reliability Review

Review the diff for new cost, fragility, or operational risk.

Check for:

1. Duplicate work, redundant I/O, or unnecessary recomputation
2. Added work on startup, render, request, or other hot paths
3. Leaks, missing cleanup, retry storms, or subscription drift
4. Ordering, race, or failure-handling problems that make the change brittle

This sub-agent is read-only. It must not edit files, apply patches, or make any other workspace changes.

Recommended sub-agent role: `reviewer`

### Sub-Agent 4: Contracts and Coverage Review

Review the diff for compatibility gaps and missing safety nets.

Check for:

1. API, schema, type, config, or feature-flag mismatches
2. Migration or backward-compatibility fallout
3. Missing or weak tests for the changed behavior
4. Missing logs, metrics, assertions, or error paths that make regressions harder to detect

This sub-agent is read-only. It must not edit files, apply patches, or make any other workspace changes.

Recommended sub-agent role: `reviewer`

Report only issues that materially affect correctness, security, privacy, reliability, compatibility, or confidence in the change. It is better to miss a nit than to bury the user in low-value noise.

## Step 3: Aggregate and Filter Findings

The main agent owns synthesis. Treat sub-agent output as raw review input, not final output.

Merge findings across all four reviewers and filter aggressively:

- drop duplicates
- drop weak or speculative claims
- drop issues that conflict with the stated intent
- drop minor style or readability comments unless they hide a real bug or maintenance risk

Normalize surviving findings into this shape:

1. File and line or nearest symbol
2. Category: regression, security, reliability, or contracts
3. Severity: high, medium, or low
4. Why it matters
5. Recommended fix or follow-up
6. Confidence: high, medium, or low

If a reviewer may be correct but the intent is unclear, turn it into an open question instead of a finding.

## Step 4: Order the Output

Present findings in this order:

1. High-severity, high-confidence issues
2. Medium-severity issues that are likely worth fixing before merge
3. Lower-severity issues or follow-ups that can wait

Keep the review 

Excerpt, first 6,000 characters of SKILL.md, verbatim from the audited commit. It is text from someone else’s repository, quoted so you can judge it before your agent reads it.

git clone https://github.com/dimillian/skills
git -C skills checkout 3c36442853dc

Works in

1. 2026-10-28
   ✓SAFE B 89 / 100

   first audit · source 3c36442853dc

Questions about review-swarm

• github.com/dimillian/skills/tree/main/review-swarm — the audited source at commit 3c36442853dc and every finding aboveObserved · 28 Oct 2026

Spotted something wrong? Report a correction · Methodology