/da-review

Summary

Single-pass devil's advocate review that finds every flaw in a target — code, plan, diff, or design — without applying any fixes.

When to use

Use /da-review when you want an adversarial critical read of something and a prioritised list of problems to act on yourself. It reviews once and stops — it does not loop, does not spawn fix agents, and does not modify any files.

Key distinction from /iterative-review: /da-review identifies problems; /iterative-review identifies and fixes them in a loop until no critical, major, or moderate issues remain. Choose /da-review when you want to stay in control of the fixes; choose /iterative-review when you want problems resolved automatically.

Typical trigger situations:

• You just finished implementing a task and want a quick adversarial sanity check before committing.
• You want to review a plan or spec for gaps before starting implementation.
• You want findings grouped by severity without any code being changed.
• You need a fast, single-pass review as input for a manual fix session.

Invocation

Pass a target to review as the argument. If no argument is supplied, the current plan or code in context is reviewed.

/da-review [target]

Parameters:

• [target] — (optional) what to review: a file path, a git diff snippet, a plan file path, or a description. If empty, the skill reviews the current plan/code/work in context.

Pre-approved tools: Read, Grep, Glob. Pre-approval does not restrict other tools; the skill's instructions forbid fixes — it only reports findings.

Severity rubric (same as /iterative-review — kept in sync):

• Critical — blocks correctness, security, or safety
• Major — significant design flaw, missing requirement, or likely bug
• Moderate — suboptimal but workable
• Minor — style, naming, or nitpick

Example 1 — Review a git diff before committing (illustrative example)

/da-review $(git diff HEAD)

## Critical
- C1: `process_payment()` calls `charge_card()` without checking the return value.
  If charge fails silently, the order is marked paid without actual payment.

## Major
- M1: No transaction rollback if `save_order()` throws after `charge_card()` succeeds.
  A crash here leaves the customer charged but orderless.

## Moderate
- Mo1: `MAX_RETRY` is hardcoded to 3; should be configurable via env var.

## Minor
- N1: Variable `tmp` in line 47 — rename to `pending_charge` for clarity.

Overall: Critical issue C1 must be fixed before this diff is safe to commit.

Example 2 — Review a plan file for gaps (illustrative example)

/da-review plans/FEAT-042-auth-redesign.md

## Critical
(none)

## Major
- M1: Task 3.2 adds a new `/logout` endpoint but no task covers session token invalidation on the server side.
  Users who log out remain authenticated until the token expires.
- M2: No rollback plan defined. If the migration in Task 4.1 fails in production, the
  previous auth tables are gone.

## Moderate
- Mo1: Acceptance criteria for Task 2.1 do not mention rate-limiting the login endpoint.

## Minor
- N1: Task numbering jumps from 3.4 to 3.6 — likely a copy-paste error.

Overall: Two major gaps that could cause a security regression — recommend addressing before implementation begins.

Related tools

• /iterative-review — Multi-agent review loop that both finds and fixes moderate-or-above issues automatically; use when you want problems resolved, not just listed.
• /aaa — Evaluates quality against world-class standards with research and gap analysis; use when you want an excellence benchmark, not just a flaw list.