adversarial-review

Adversarial Review

Purpose

Critique the code change from an adversarial perspective. Look for things that are wrong, risky, incomplete, or unnecessary. This is the "is this correct and safe?" pass.

When to Use

• DO: Use when dispatched by the /code-reviewer:review or /code-reviewer:review:adversarial command
• DO NOT: Use for style or test coverage concerns — those have dedicated phases

Input

You receive:

• A full-scope review brief covering all review units and the complete change
• All reference docs (style guide, testing practices, security posture, API conventions)
• The project context from the config file's markdown body

Review Focus

Self-adjust your depth based on the change's risk and complexity. A trivial rename gets a light pass. A new auth flow gets deep scrutiny.

Architecture & Design

• Are the design decisions sound for this codebase?
• Does the change introduce unnecessary coupling or complexity?
• Is the abstraction level appropriate?
• YAGNI check: before suggesting additions, verify they're actually needed — grep the codebase for usage

Correctness

• Are there logic errors, off-by-one mistakes, race conditions?
• Are edge cases handled (nil/null, empty collections, boundary values)?
• Does error handling cover failure paths?
• Are assumptions documented or validated?

Security

• Injection vectors (SQL, command, XSS)?
• Authentication/authorization gaps?
• Secrets or credentials exposed?
• Input validation at system boundaries?
• Sensitive data in logs or error messages?

API Compatibility

• Do changes to APIs maintain backward compatibility?
• Are breaking changes documented?
• Do API contracts (request/response shapes, status codes) remain consistent?
• For cross-repo projects: are dependent repos affected?

Cross-Unit Concerns

• Do changes in one area require corresponding changes in another?
• Are interfaces between components still consistent?
• Does the change affect shared state or global configuration?

Output

Use the templates/phase-report.md format. Tag your phase as [adversarial] in each finding.

Critical Rules

• Be specific. Every issue must reference a file:line. No vague "improve error handling."
• Explain why. State the consequence of not fixing the issue.
• Suggest how. If the fix isn't obvious, provide guidance.
• Acknowledge strengths. Good architecture, clean patterns, thorough error handling — call them out.
• Grade severity honestly. Not everything is Critical. Reserve Critical for bugs, security issues, and data loss risks.
• No performative language. Findings are technical assessments, not social commentary.
• YAGNI. If you're about to suggest adding something, check if it's needed first.