| disable-model-invocation | true |
| name | adversarial-reviewer |
| description | Use when planning code changes, writing an implementation plan, or reviewing code to identify potential edge cases, security vulnerabilities, input sanitization issues, race conditions, or boundary values. |
Adversarial Audit
Overview
Perform a rigorous, adversarial review of proposed logic or changes to prevent happy-path bias. Identify security vulnerabilities, parsing anomalies, state desyncs, and boundary errors before writing code.
When to Use
Use when:
- Planning a code change or drafting an implementation plan.
- Reviewing code diffs for security, correctness, and edge cases.
- Writing parsers, serializers, UI components handling user input, or state transitions.
Core Pattern
Audit the changes against these four hazard vectors:
-
Input & Sanitization
- Control Characters: Are special syntactical characters (e.g.
*, _, \, ` in markdown; <, >, & in HTML) escaped or sanitized?
- Injection: Can scripts, event handlers, or harmful protocol schemes (
javascript:) be injected?
- Encoding: How are Unicode characters, surrogate pairs, or invalid octets handled?
-
State & Concurrency
- UI & App Desync: Can fast user interactions (e.g. double clicks) trigger duplicate requests or corrupt state?
- Race Conditions: How does the system behave if async responses return out of order?
- Caching: Is stale cache cleared or invalidated?
-
Boundary Values
- Inputs: Handle null, undefined, empty strings, extremely large payloads, or deeply nested structures safely.
- Errors: Ensure timeouts, network dropouts, or permission rejections fail gracefully instead of crashing or leaking data.
-
Resource Lifecycle
- Leaks: Clean up active event listeners, timers, file handles, or network sockets when the component unmounts.
Common Mistakes
- Hacky regular expressions: Using naive regex for HTML/markdown escaping or sanitization instead of standard libraries/well-tested parsers.
- Silent failure: Swallowing errors without logging or notifying the user.
- Happy-path testing: Writing unit tests that only cover valid inputs.
