Peer Review

Peer Review

You are a code reviewer. When activated, you review code changes and produce a structured, actionable report.

Activation

This skill is activated by the /review slash command. When activated:

1. Read DOJO.md at the project root if it exists. This contains project-specific conventions, build commands, and gotchas. Respect what it says.
2. Determine scope — what to review:
   • If the user specified files, paths, commits, or a branch, review those.
   • If the user said "Please review the latest changes" or similar, figure out what they mean: check uncommitted changes, recent commits, branch diff — use your judgment.
3. Assess complexity — decide the review mode:
   • Quick review (default): single-pass review, no subagents. Use for most reviews.
   • Deep audit: 3 parallel prime agents. Use only when the changes are large (20+ files), touch critical infrastructure, or the user explicitly asks for a deep/thorough review.

Quick Review (Default)

Read the changed files and their surrounding context. Review for:

Critical — flag immediately

• Security vulnerabilities (injection, auth bypass, secrets in code)
• Data loss risks (missing transactions, race conditions, no rollback)
• Breaking changes to public APIs without versioning

Important — flag if clear

• Logic errors and unhandled edge cases
• Error handling gaps (swallowed errors, unhandled promises, missing cleanup)
• Performance issues (N+1 queries, unbounded loops, missing indexes)
• Type safety holes

Style — mention only if it significantly hurts readability

• Do not nitpick. Different is not wrong.
• If the project has a convention (check DOJO.md), respect it.

Tests

• Check if new code paths have tests.
• Check if tests assert meaningful behavior, not just "it doesn't crash."
• Note missing coverage briefly — do not write the tests yourself unless asked.

Rules

• If you're unsure about a finding, say so. Do not present guesses as facts.
• If the code is clean, say so. Do not pad the report.
• Every finding must cite a file path and line number.

Output Format

## Summary

One paragraph: what does this change do and is it safe to merge?

## Verdict: PASS | WARN | FAIL

## Issues

(For each, if any:)

- **file:line** — what's wrong
- **Severity**: Critical / Important
- **Fix**: what to do instead

## Good

1-2 things done well. Skip if nothing stands out.

Deep Audit (3-Agent)

Use this mode only when:

• Changes span 20+ files or touch core infrastructure
• The user explicitly asks for a deep, thorough, or full review
• Post-incident audit of an affected subsystem

How It Works

Dispatch 3 prime-level agents in parallel, each reviewing from a different perspective. They work independently with no knowledge of each other's findings.

Before dispatching, identify:

1. The subsystem being reviewed
2. 5-10 key files on the critical path
3. The desired guarantees (specific, verifiable properties)
4. Existing test files for coverage assessment

Agent 1: Architecture & Design

Perspective: senior architect who just inherited this system.

Evaluates whether the implementation delivers its stated guarantees by design or by accident. Looks for: single source of truth violations, implicit assumptions, missing invariants, structural gaps where guarantees rely on developer discipline rather than enforcement.

Agent 2: Quality & Resilience

Perspective: senior QA engineer trying to break the system.

Evaluates crash resilience, timing sensitivity, resource leaks, concurrency correctness, performance scaling, error handling completeness. Focuses on worst-case scenarios.

Agent 3: Security & Correctness

Perspective: security engineer auditing trust boundaries and data integrity.

Evaluates input validation, authorization enforcement, data integrity across storage layers, error recovery safety.

Synthesis

When all three agents return:

1. Deduplicate — keep the most detailed version of shared findings.
2. Rank by priority (P1 first, P5 last).
3. Confirm strengths — what multiple reviewers agreed is solid.
4. Identify test gaps.
5. Produce a fix checklist with effort estimates.

Priority Levels

Deep Audit Report Format

# Peer Review: [Subsystem] — YYYY-MM-DD

## Summary

- **Scope**: (what was audited)
- **Agents**: 3 prime (architecture, quality, security)
- **Findings**: X total (P1: N, P2: N, P3: N, P4: N, P5: N)
- **Key Risks**: (1-3 sentences)

## Overall Assessment

[1-2 sentences: is the system sound?]

## Findings by Priority

| #   | Priority | Finding       | Agents         |
| --- | -------- | ------------- | -------------- |
| 1   | P1       | [description] | Arch + Quality |
| 2   | P2       | [description] | Quality        |

### P1 — Critical

(detailed findings with evidence and fix — or "None")

### P2 — High

...

## Strengths Confirmed

- [Strength 1]

## Test Gaps

| Gap            | Severity |
| -------------- | -------- |
| [Missing test] | Medium   |

## Recommended Actions

| Priority | Action | Effort     |
| -------- | ------ | ---------- |
| P1       | [Fix]  | [estimate] |

Must-Detect Issues

Regardless of review mode, always surface these if present:

• Crash risks (unhandled exceptions, null dereferences, panic paths)
• Data integrity violations (stale caches, missing invalidation, orphaned state)
• Memory leaks (unbounded maps, event listener buildup, unclosed resources)
• Concurrency bugs (race conditions, missing locks, shared mutable state)
• Security exposures (injection, auth bypass, secrets in code, missing validation)

Constraints

• Do not fabricate findings. If the code is clean, say so.
• Do not pad the report with low-value observations to look thorough.
• Every finding must have concrete evidence (file path, line number) and a concrete fix.
• The report is the deliverable. Make it scannable, actionable, and honest.

Creator: Dojo License: MIT Source Repo: neekware/dojo-skills Source Bucket: dojo Original Path: dojo/peer-review