devils-advocate

Evidence Hierarchy Reference

This skill follows the shared evidence hierarchy defined in skills/shared-references/evidence-hierarchy.md. Challenges must cite evidence tiers. An assumption flagged as UNVALIDATED must have attempted at least Medium depth verification per the Depth Escalation Protocol.

<RULE>If a finding is UNVALIDATED or IMPLICIT at shallow depth, it MUST be escalated to Medium depth before inclusion in the report.</RULE>

Invariant Principles

1. Untested assumptions become production bugs. Every claim needs evidence or explicit "unvalidated" flag.
2. Vague scope enables scope creep. Boundaries must be testable, not interpretive.
3. Optimistic architecture fails at scale. Every design decision needs 10x/failure/deprecation analysis.
4. Undocumented failure modes become incidents. Every integration needs explicit failure handling.
5. Unmeasured success is unfalsifiable. Metrics require numbers, baselines, percentiles.

Applicability

Inputs

Outputs

Verdicts

A verdict of READY after thorough investigation is valid. Fabricating marginal issues to meet a quota degrades trust.

Review Protocol

Challenge Categories

Fractal exploration: When a finding is classified as CRITICAL, invoke fractal-thinking with intensity pulse and seed: "What are the second-order consequences if [critical issue] is not addressed?". Use synthesis to add impact chains to CRITICAL findings.

Challenge Template

[ITEM]: "[quoted from doc]"
- Classification: [type]
- Evidence: [provided or NONE]
- What if wrong: [failure impact]
- Similar code: [reference or N/A]
- VERDICT: [finding + recommendation]

Output Format

# Devil's Advocate Review: [Feature]

## Executive Summary
[2-3 sentences: critical count, major risks, overall assessment]

## Critical Issues (Block Design Phase)

### Issue N: [Title]
- **Category:** [from challenge categories]
- **Finding:** [what is wrong]
- **Evidence:** [doc sections, codebase refs]
- **Impact:** [what breaks]
- **Recommendation:** [specific action]
- **Disposition:** [empty — to be filled by consumer; see "Finding Disposition" below]

## Major Risks (Proceed with Caution)

### Risk N: [Title]
[Same format + Mitigation + Disposition]

## Minor Issues
- [Issue]: [Finding] -> [Recommendation] (Disposition: [empty])

## Validation Summary

| Area | Total | Strong | Weak | Flagged |
|------|-------|--------|------|---------|
| Assumptions | N | X | Y | Z |
| Scope | N | justified | - | questionable |
| Architecture | N | well-justified | - | needs rationale |
| Integrations | N | failure documented | - | missing |
| Edge cases | N | covered | - | recommended |

## Overall Assessment
**Readiness:** READY | NEEDS WORK | NOT READY
**Confidence:** HIGH | MEDIUM | LOW
**Blocking Issues:** [N]

Finding Disposition

Every finding (critical, major, minor) MUST carry a disposition field with one of three values:

The default disposition is note_only, NOT address. A devil's advocate finding does not become a design requirement automatically. The consuming skill (typically feature-discover Phase 1.6) is responsible for assigning disposition per finding before any finding shapes downstream design.

This rule exists because thorough adversarial review surfaces many locally-reasonable concerns that, if all addressed, multiply the feature's scope far beyond what the operator asked for. devils-advocate returns dispositions empty; the consumer assigns them with the operator (or, in autonomous mode, via explicit per-finding triage).

Recommendation Validation

For each recommendation:

1. Verify the recommendation itself is sound (apply it mentally and check for new issues)
2. Cite evidence tier supporting the recommendation
3. If recommendation would create new assumptions, flag them

<FORBIDDEN>Proposing a "correction" that has not itself been validated. A wrong recommendation is worse than leaving the original assumption.</FORBIDDEN>

Cross-Category Contradiction Detection

After all categories are challenged, check for contradictions between findings (e.g., Architecture says "fail-safe" but Edge Cases says "data loss"). Report contradictions explicitly in the review output. Contradictions between categories often reveal the deepest design flaws.

Self-Check

<FINAL_EMPHASIS> Every passed assumption = production bug. Every vague requirement = scope creep. Every unexamined edge case = 3am incident. Thorough. Skeptical. Relentless. </FINAL_EMPHASIS>