vm-adversarial-design-challenger

# VM Adversarial Design Challenger

## Overview

Relentlessly interrogates an architecture proposal, design decision, or plan from multiple challenge angles until every significant branch of the decision tree has been examined. Produces a challenge report with open questions, unresolved trade-offs, and recommended resolution steps. Every question must be answerable — if it cannot be resolved by the proposer, it becomes a risk item.

This skill does NOT block decisions. It surfaces what has not been considered so the proposer can make an informed choice.

## When to Use

- Before approving a significant architectural change
- When a design proposal feels complete but the team has a nagging sense something is missing
- When a PRD or change plan contains architectural decisions that need stress-testing
- When a team is about to commit to a technology choice that will be expensive to reverse
- As part of a pre-implementation governance checkpoint

## When NOT to Use

- For trivial changes where reversal cost is low
- When the goal is to block a decision rather than improve it (this skill informs, does not veto)
- For post-implementation review (use Architectural Review Agent instead)

## Inputs

```json
{
  "proposal": "Text or file path describing the architecture decision, design, or plan",
  "known_constraints": ["List of constraints the proposer has already factored in"],
  "challenge_depth": "quick (10 questions) | standard (20 questions) | thorough (unlimited)"
}
```

## Challenge Axes (MUST cover all axes)

The skill MUST interrogate the proposal across all of the following axes. For each axis, generate between 1 and 5 specific, pointed questions depending on relevance:

### 1. Reversibility
- What would it cost to undo this decision in 6 months?
- What coupling does this introduce that would make reversal expensive?
- Is there a reversible version of this decision that provides 80% of the value?

### 2. Failure Modes
- What is the failure mode if the primary assumption is wrong?
- What happens under peak load? Under zero load?
- What is the degraded mode when a dependency is unavailable?

### 3. Dependency Risk
- What external systems or teams does this depend on?
- What happens if those dependencies change their API or fail?
- Are there hidden transitive dependencies (the dependency of the dependency)?

### 4. Testability
- How will this be unit tested without mocking the entire system?
- How will integration tests detect a regression in this component?
- What observability (logging, metrics, tracing) is needed to diagnose failures in production?

### 5. Scalability and Performance
- At what data volume or request rate does this design break down?
- Is the bottleneck the CPU, memory, network, or database?
- Does horizontal scaling work at the identified bottleneck?

### 6. Security Boundaries
- Where are trust boundaries crossed in this design?
- What data flows across a trust boundary without validation?
- Is there a privilege escalation