adversarial-verifier

Files (1)

• SKILL.md

SKILL.md (first lines)

# Adversarial Verifier

The agent that doesn't trust the implementor. Reviews code with opposing goals:
the implementor optimized for "it works," the verifier optimizes for "it won't break."

## Input

Requires:
1. Completed module code (output of `/ai-coding-coach`)
2. PRD acceptance criteria (from `/prd-generator`)
3. Constitution rules (from `/constitution`)

If any is missing, stop and tell the user which skill to run first.

## Philosophy

You are the VERIFIER, not the implementor. Your job is to FIND FAULTS,
not to praise. Assume every function has a bug until proven otherwise.

## Workflow

### Step 1: Load Context

Read these files:
- The completed module's code
- The PRD (specifically the acceptance criteria for this module)
- The Constitution (security and testing rules)

### Step 2: Spec Compliance Check

For each acceptance criterion in the PRD, verify:

```markdown
| Criterion | Status | Evidence |
|-----------|--------|----------|
| "User can register with email" | ✅ PASS | POST /api/auth/register exists, validates email |
| "Password must be hashed" | ✅ PASS | bcrypt used in auth.service.ts:45 |
| "Duplicate email rejected" | ❌ FAIL | No unique constraint check before insert |
| "Rate limiting on signup" | ❌ FAIL | No rate limiter on /register endpoint |
```

### Step 3: Security Audit

Run this checklist against every endpoint:

```markdown
## Security Checklist

### Input Validation
- [ ] All endpoints validate request body with Zod/Joi
- [ ] Path parameters are validated (not just trusted)
- [ ] Query parameters are validated
- [ ] File uploads check type and size

### Authentication
- [ ] Protected endpoints check JWT/session
- [ ] Token expiration is enforced
- [ ] Role-based access is checked (not just "is logged in")

### Data Safety
- [ ] SQL queries use parameterized inputs
- [ ] No user input in SQL strings
- [ ] Sensitive data (passwords, tokens) not in responses
- [ ] Error messages don't leak internal details

### Rate Limiting
- [ ] Public endpoints have rate limits
- [ ] Auth endpoints have stricter limits
- [ ] File upload endpoints have size limits
```

### Step 4: Code Quality Review

Review for anti-patterns:

```markdown
## Code Quality Findings

| File | Line | Issue | Severity | Fix |
|------|------|-------|----------|-----|
| auth.service.ts | 42 | Missing try/catch on bcrypt | HIGH | Wrap in try/catch |
| orders.service.ts | 15 | Function > 30 lines | MEDIUM | Extract helper |
| products.controller.ts | 8 | Using `any` type | LOW | Replace with proper type |
```

### Step 5: Edge Case Analysis

For each endpoint, ask "what could go wrong?":

```markdown
## Edge Cases

### POST /api/auth/register
- Empty body → Should return 400 (CHECK: does it?)
- Invalid email format → Should return 400
- Duplicate email → Should return 409
- Very long name (> 100 chars) → Should return 400
- SQL injection attempt → Should be caught by parameterized queries
- Concurrent duplicate registration → Race condition risk

### GET /api/orders/:id
- Non-existent ID → Should return 404
- ID of another user's order → Should return 403 (not 404!)
- Invalid UUID format → Should return 400
```

### Step 6: Generate Verdict

Output one of three verdicts:

```markdown
## Verification Verdict: [PASS / CONDITIONAL / FAIL]

### PASS
All acceptance criteria met. No security issues. Code quality acceptable.
Module is ready for deployment.

### CONDITIONAL
[X] issues found that should be fixed before deployment:

From susantosanto/config-opencode, MIT.

More from susantosanto/config-opencode