coherence-reviewer
SkillDocs & knowledgeThe 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.
Account requirements not reviewed. Check the skill instructions before use; Ahel provides instructions and does not run this skill.
No other account needed.
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
- Have a planning document written and available for the agent to read.
- Make sure the document-review skill is available, since it spawns the coherence-reviewer.
- Run a document review over the planning document so the coherence-reviewer is invoked.
- 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
Related picks
Skill · larksuite
The pick for Markdownmarkdown-formatter
Skill · nvidia
The pick for Markdownhandoff
Skill · mattpocock
More in Docs & knowledgecanvas-design
Skill · anthropics
More in Docs & knowledgedoc-coauthoring
Skill · anthropics
More in Docs & knowledgedefuddle
Skill · kepano
More in Docs & knowledge