review-swarm v0.1.0A

Immutable. This exact content is served forever at /api/v1/blob/27cfba3a3bd3964f.

---
name: review-swarm
description: Use when reviewing a known change set through parallel read-only code, architecture, test, safety, or product lanes with disjoint concerns and one integrator verdict.
version: 0.1.0
author: GameStudio-CodexKIT
license: MIT
compatibility:
  engines: [engine-agnostic, unity]
  versions: [any]
  platforms: [windows, linux, macos]
metadata:
  studio:
    type: workflow
    lifecycle_stage: review
    risk_level: read-only
    packs: [studio-core]
    side_effects: none
    artifact: review-verdict.md
    required_evidence: [lane-findings, affected-paths, integrator-verdict]
    owner: HoaTV Studio
    reviewer: null
    maturity: beta
    last_reviewed: 2026-08-07
    provenance:
      derived_from:
        repo: Dimillian/Skills
        path: review-swarm/SKILL.md
        commit: 05ba982bfeb0d77d3c97d4542b0ee15034d05f84
        license: MIT
      patterns_from: [AGENTS.md multi-agent ownership]
      copied_text: none
---
# Review Swarm

## Overview
Parallelize independent review questions, never write ownership. Reviewers remain read-only and the integrator owns deduplication and the final verdict.

## When to use
Use for a known diff, pull request, generated output, architecture change, safety review, or release candidate that benefits from independent lenses.

## When NOT to use
Do not use when the failure is unknown and needs hypothesis discovery; route that work to `bug-hunt-swarm`. Do not use when lanes would need to edit the same files.

## Required inputs and context discovery
Require the exact change set, repository snapshot, review questions, lane boundaries, affected paths, applicable contracts, severity model, and integrator owner.

## Safety and risk level
All lanes are read-only. Reviewers may inspect files and run non-mutating checks but may not edit, commit, start services, import data, or alter generated state.

## Workflow
1. Freeze the review target and define non-overlapping lane questions.
   Completion criterion: every concern has one lane and no lane owns writes.
2. Give each lane the minimum repository context and exact evidence format.
   Completion criterion: lane reports cite affected paths and concrete evidence.
3. Run lanes independently without sharing conclusions mid-review.
   Completion criterion: findings are not contaminated by another lane’s verdict.
4. Integrate, deduplicate, calibrate severity, and record counterevidence.
   Completion criterion: each retained finding is actionable and source-backed.
5. Issue PASS, NEEDS WORK, or BLOCKED and assign fixes to a separate write owner.
   Completion criterion: reviewers still have no write scope.

## Evidence and output contract
Produce lane reports, affected locations, evidence, counterevidence, severity, recommended next step, and one integrator verdict.

## Handoff contract
Record target revision, lane assignments, commands run, findings accepted or rejected, unresolved disagreements, and exact write-owner follow-ups.

## Pitfalls and anti-rationalization
- More lanes do not improve quality when concerns overlap.
- Reviewers may not “quickly fix” issues they discover.
- A clean static review does not prove runtime behavior.
- Duplicate findings must not inflate severity.

## Verification checklist
- [ ] Target revision is fixed.
- [ ] Lanes are independent and read-only.
- [ ] Findings cite paths and evidence.
- [ ] Integrator verdict handles duplicates and counterevidence.
- [ ] Any fixes have separate ownership.

## References and scripts
Use repository diffs and native static checks as read-only evidence sources. The kit-maintenance helpers `scripts/validate.py` and `scripts/secret_scan.py` are available only in a full repository clone.