# Vdd Adversarial

> Use when performing Verification-Driven Development with adversarial approach. Actively challenge assumptions and find weak spots.

- Skill: `tomevault-io/vdd-adversarial` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add tomevault-io/vdd-adversarial`
- Raw SKILL.md: https://api.skillmd.com/api/skills/tomevault-io/vdd-adversarial/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: tomevault-io (https://skillmd.com/u/tomevault-io)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/tomevault-io/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.
- **Forced Negativity**: Zero tolerance for "lazy" AI patterns (placeholder comments, generic error handling, inefficient loops).
- **Context Resetting**: Each adversarial review MUST use a fresh context to prevent "relationship drift."
- **Linear Accountability**: Every line of code MUST trace to a corresponding issue and verification step.

### Convergence Signal (Exit Strategy)
The review cycle STOPS when the Adversary's critiques become **hallucinated** — fabricated problems that do not exist in the code. This signals "Maximum Viable Refinement" (Zero-Slop).

## 3. Challenge Assumptions
- **Question Everything**: Do NOT accept the "happy path" as truth.
- **Input Validation**: What if input is null? Too long? Invalid chars?
- **State**: What if the DB is down? API is slow? Disk full?

## 4. Decision Tree
1. **Is it clear?** -> If not, REJECT.
2. **Is it safe?** -> If not, REJECT.
3. **Does it break anything?** -> Check regression.
4. **Is it tested?** -> If not, REJECT.

## 5. Failure Simulation
- **Simulate Failures**: Mentally (or physically) simulate network failures, timeouts, permission errors.
- **Check Error Handling**: Ensure graceful degradation, not silent swallowing.

## 6. Output Artifacts

If the User or Workflow requests a **Report**, **Critique**, or **Artifact**, you **MUST** use the standard template found in:
`assets/template_critique.md`

Read this file using `view_file` before generating the report.

## 7. Rationalization Table

| Agent Excuse | Reality / Counter-Argument |
| :--- | :--- |
| "The code passes existing tests" | Tests only cover known scenarios. Adversarial review targets unknown unknowns. |
| "This edge case is too unlikely" | Production systems encounter "unlikely" cases daily at scale. |
| "I don't want to be too harsh" | VDD requires Forced Negativity. Politeness hides bugs. |

## 8. Examples
> [!TIP]
> See `examples/usage_example.md` for a complete adversarial critique walkthrough.

---
> Converted and distributed by [TomeVault](https://tomevault.io/claim/matrixfounder) — claim your Tome and manage your conversions.
<!-- tomevault:4.0:skill_md:2026-04-13 -->