consistency-checker

Consistency Checker Agent

Detect contradictions and inconsistencies between vault notes that cover overlapping topics. Report conflicts with evidence from both sides and suggest resolution.

Common References

Refer to skills/common/references/cli-basics.md for Obsidian CLI common patterns.

Procedure

Phase 1: Identify Topic Clusters

Find groups of notes that discuss the same or closely related topics.

1a. Tag-based clustering

obsidian tags counts sort=count format=json

For each tag with 3+ notes, those notes form a cluster.

1b. Folder-based clustering

Notes in the same folder/subfolder are likely related.

obsidian folders

For each folder, list its notes.

1c. Semantic clustering

Use qmd to find notes with high content similarity:

For a sample of notes (or user-specified scope):

mcp__qmd__query with:
- searches: [vec: <note content summary>]
- minScore: 0.5
- limit: 10

Notes that appear as high matches for each other form semantic clusters.

Phase 2: Extract Claims Per Cluster

For each cluster, read the notes and extract factual claims:

1. Read note content: obsidian read file=<name>
2. Identify statements of fact (not opinions, not code examples):
   • "X uses Y architecture"
   • "The default value of Z is 10"
   • "Since version 5.4, feature W was added"
   • "Function F accepts parameters A, B, C"
3. Tag each claim with:
   • Source note
   • created date from frontmatter
   • source field (if available)

Phase 3: Detect Contradictions

Compare claims within each cluster:

Contradiction Type	Example	Severity
Direct conflict	Note A: "X is deprecated", Note B: "Use X for this"	Critical
Version mismatch	Note A describes UE5.1 behavior, Note B describes UE5.4	High
Parameter conflict	Note A: "default is 10", Note B: "default is 100"	High
Scope mismatch	Note A: "X always does Y", Note B: "X does Y only when Z"	Medium

Resolution hints:

• Compare created dates — newer note may reflect updated info
• Compare source fields — primary source > secondary
• Check if one note qualifies the other (scope mismatch vs actual conflict)

Phase 4: Generate Report

# Consistency Report — YYYY-MM-DD

## Summary
| Metric | Count |
|--------|-------|
| Clusters analyzed | N |
| Contradictions found | M |
| Critical | C |
| High | H |
| Medium | L |

## Contradictions

### 1. [Critical] Topic: <topic>
**Note A**: [[note-a]] (created: 2026-01-15, source: "Official Docs v5.1")
> "AttributeSet requires manual replication setup"

**Note B**: [[note-b]] (created: 2026-04-01, source: "UE5.4 Release Notes")
> "UE5.4 introduces automatic replication for AttributeSets"

**Analysis**: Version mismatch — Note A describes pre-5.4 behavior.
**Suggested resolution**: Update Note A to reflect UE5.4 changes, mark old behavior as legacy.

### 2. [High] Topic: <topic>
...

---

## Resolution Options
1. Resolve all (apply suggested fixes)
2. Resolve per item
3. Report only (no changes)

Phase 5: Apply Resolutions After Approval

For each approved resolution:

• Version mismatch: Update the older note to reflect current info, or add a version-specific note:

  obsidian append file=<name> content="\n\n> **Note (YYYY-MM-DD)**: As of version X.Y, this behavior has changed. See [[newer-note]]."
  

• Direct conflict: User decides which is correct. Update or annotate the incorrect one.

• Scope mismatch: Clarify the scope in both notes. Add qualifiers.

Phase 6: Auto-Commit

VAULT_PATH=$(obsidian vault info=path)
git -C "$VAULT_PATH" add -A
git -C "$VAULT_PATH" commit -m "consistency-checker: resolve N contradictions YYYY-MM-DD"

Scoping

To avoid scanning the entire vault every time:

• User-specified scope: /consistency-check 후디니/DOP → only that folder
• Post-ingestion: After inbox-ingest, check only the notes that were modified/created
• Tag-scoped: /consistency-check #언리얼 → only notes with that tag
• Full scan: No argument → full vault (may be slow for large vaults)

Accept scope from $ARGUMENTS.

Rules

• Never modify notes without user approval.
• Focus on factual claims, not stylistic differences.
• When suggesting resolution, always explain WHY one version is preferred (date, source authority, specificity).
• If both claims could be valid in different contexts, suggest adding scope qualifiers rather than deleting either.
• Process clusters in priority order: Critical → High → Medium.
• Maximum 20 contradictions per report to keep review manageable.