contradiction-mapper

“This skill is a document analysis tool with no dangerous patterns. It has clear, narrowly scoped functionality (finding contradictions), explicit boundaries (surfacing, not resolving), no tool overreach, no secrets exfiltration, no identity impersonation, and no spawn abuse. The scope is well-defined and honest about what it does and doesn't do.”

---
name: contradiction-mapper
description: >
  Systematically identify and map contradictions within a single document or
  between multiple documents. Use when you need to find where a body of text
  disagrees with itself — hidden policy conflicts, inconsistent specs,
  evolving narratives that were never reconciled.
triggers:
  - two documents are supposed to agree but the user suspects they do not
  - a spec or policy seems internally inconsistent
  - agent handoffs produced conflicting outputs that need reconciliation
steps:
  - Extract all factual or normative claims from each document (one claim per line)
  - Tag each claim with its source location (doc, section, line)
  - Compare claims pairwise for logical conflict: A contradicts B if believing A makes B false
  - For each contradiction: record both claims, their locations, severity (hard | soft), and a suggested resolution
  - Produce a contradiction map sorted by severity
notes:
  - Soft contradictions are tensions or inconsistencies that do not strictly exclude each other
  - Hard contradictions are logical impossibilities (X cannot be both true)
  - Do not resolve contradictions — surface them. Resolution is for the human.
  - Silence can be a contradiction: if doc A says "always do X" and doc B never mentions X, flag it
---

# Contradiction Mapper Skill

## Purpose
Truth is fragile in long documents. Claims made in section 1 get quietly
contradicted in section 7. Policies written in 2024 conflict with updates
written in 2025. This skill finds those fractures before they cause problems.

## When to Use
- Reconciling two versions of a spec or policy
- Auditing a codebase where comments conflict with behaviour
- Verifying that a plan is internally consistent before execution
- Post-mortem analysis: finding where assumptions diverged from reality

## Claim Extraction Format
```
[doc-A § 2.1]: "All requests must be authenticated"
[doc-B § 4.3]: "Public endpoints do not require auth headers"
```

## Contradiction Record Format
```json
{
  "id": "C-001",
  "claim_a": { "source": "doc-A § 2.1", "text": "All requests must be authenticated" },
  "claim_b": { "source": "doc-B § 4.3", "text": "Public endpoints do not require auth headers" },
  "type": "hard | soft",
  "severity": "high | medium | low",
  "note": "The scope of \"all requests\" in doc-A is ambiguous — does it include public endpoints?",
  "suggested_resolution": "Clarify doc-A to exempt endpoints tagged as public"
}
```

## Severity Guidelines
- **High**: The contradiction would cause incorrect behaviour if either claim is followed literally
- **Medium**: The contradiction creates ambiguity that requires a judgement call
- **Low**: A stylistic or terminological inconsistency unlikely to cause operational problems

## Output Structure
```
## Contradiction Map

### Hard Contradictions
[list with resolution suggestions]

### Soft Contradictions / Tensions
[list]

### Summary
- N hard contradictions found
- N soft contradictions found
- Highest risk: [C-001]
```

## Key Insight
The most dangerous contradictions are the ones that look like they agree on
the surface. Read the edge cases, not the headlines.