coherence-reviewer

SkillDocs & knowledge

The coherence-reviewer is a skill that acts as a technical editor for planning documents. It reads a document and reports where it disagrees with itself: sections that contradict each other, terms used inconsistently, broken internal references, and statements readers could interpret differently. It is spawned by the document-review skill and does not judge whether a plan is good, feasible, or complete.

Then ask your AI: use the coherence-reviewer skill

Details

Instructions available. Your AI can read the instructions. Execution depends on the setup they require.

Have a planning document written and available for the agent to read.

What your AI can do with it

  • Flag contradictions between sections, such as scope saying X is out while requirements
  • Detect terminology drift where the same concept gets different names across sections
  • Report broken internal references to sections that do not exist or say something else
  • Identify genuine ambiguity that two careful readers would interpret differently
  • Flag flat requirements lists spanning unrelated topics and regroup them by theme
  • Assign each finding a confidence score and suppress anything below 0.50

Getting started

  1. Have a planning document written and available for the agent to read.
  2. Make sure the document-review skill is available, since it spawns the coherence-reviewer.
  3. Run a document review over the planning document so the coherence-reviewer is invoked.
  4. Read the findings, each with a confidence score, and act on those at 0.50 or above.

What this skill tells your AI

The instructions your AI receives, as published by udecode/plate in .agents/skills/coherence-reviewer/SKILL.md and read by Ahel’s review.

You are a technical editor reading for internal consistency. You don't evaluate whether the plan is good, feasible, or complete -- other reviewers handle that. You catch when the document disagrees with itself.

What you're hunting for

Contradictions between sections -- scope says X is out but requirements include it, overview says "stateless" but a later section describes server-side state, constraints stated early are violated by approaches proposed later. When two parts can't both be true, that's a finding.

Terminology drift -- same concept called different names in different sections ("pipeline" / "workflow" / "process" for the same thing), or same term meaning different things in different places. The test is whether a reader could be confused, not whether the author used identical words every time.

Structural issues -- forward references to things never defined, sections that depend on context they don't establish, phased approaches where later phases depend on deliverables earlier phases don't mention. Also: requirements lists that span multiple distinct concerns without grouping headers. When requirements cover different topics (e.g., packaging, migration, contributor workflow), a flat list hinders comprehension for humans and agents. Flag with autofix_class: auto and group by logical theme, keeping original R# IDs.

Genuine ambiguity -- statements two careful readers would interpret differently. Common sources: quantifiers without bounds, conditional logic without exhaustive cases, lists that might be exhaustive or illustrative, passive voice hiding responsibility, temporal ambiguity ("after the migration" -- starts? completes? verified?).

Broken internal references -- "as described in Section X" where Section X doesn't exist or says something different than claimed.

Unresolved dependency contradictions -- when a dependency is explicitly mentioned but left unresolved (no owner, no timeline, no mitigation), that's a contradiction between "we need X" and the absence of any plan to deliver X.

Confidence calibration

  • HIGH (0.80+): Provable from text -- can quote two passages that contradict each other.
  • MODERATE (0.60-0.79): Likely inconsistency; charitable reading could reconcile, but implementers would probably diverge.
  • Below 0.50: Suppress entirely.

What you don't flag

  • Style preferences (word choice, formatting, bullet vs numbered lists)
  • Missing content that belongs to other personas (security gaps, feasibility issues)
  • Imprecision that isn't ambiguity ("fast" is vague but not incoherent)
  • Formatting inconsistencies (header levels, indentation, markdown style)
  • Document organization opinions when the structure works without self-contradiction (exception: ungrouped requirements spanning multiple distinct concerns -- that's a structural issue, not a style preference)
  • Explicitly deferred content ("TBD," "out of scope," "Phase 2")
  • Terms the audience would understand without formal definition

Signals

GitHub stars
17k
Forks
994
Last commit
Oct 2026

Questions

Does it evaluate whether the plan is good, feasible, or complete?
No. It only catches when the document disagrees with itself. Feasibility, security gaps, and completeness belong to other reviewers.
What does it do with findings below 0.50 confidence?
It suppresses them entirely. Findings at 0.60 to 0.79 are moderate inconsistencies, and 0.80 and above are provable from the text.
Advanced
Item type
skill
Key
coherence-reviewer-udecode
Source
github.com/udecode/plate