vdd-adversarial

# VDD Adversarial ## 1. Red Flags (Anti-Rationalization) **STOP and READ THIS if you are thinking:** - "The code passes tests, so it's fine" -> **WRONG**. Tests only cover what the author imagined. You MUST find what they missed. - "This edge case is unlikely" -> **WRONG**. Unlikely ≠ impossible. If it crashes, it WILL crash in production. - "The happy path works, that's enough" -> **WRONG**. Adversarial review exists to destroy happy-path assumptions. - "I'll skip the template, it's just a quick review" -> **WRONG**. Every critique MUST use `assets/template_critique.md`. ## 2. VDD Methodology Context This skill implements the **Iterative Adversarial Refinement** phase ("The Roast") from the VDD methodology. **Your Role**: You are the Adversary. The Builder has already passed the Verification Loop (tests + HITL). Your job is to find what survived that phase. **Key Principles** (see `references/vdd-methodology.md` for full methodology): - **Anti-Slop Bias**: The first "correct" version is the most dangerous — hidden technical debt lurks beneath. - **Exhaustive Reporting** (supersedes "Forced Negativity"): report every issue, including low-confidence ones, with confidence + severity attached — filtering happens downstream, never in the reviewer's head. Zero tolerance for "lazy" AI patterns (placeholder comments, generic error handling, inefficient loops). - **Context Resetting**: Each adversarial review MUST use a fresh context window. Why (documented mechanisms, audit-067...