Skip to content

Paraphrase-First Review: A Zero-Context Reader Restates the Design Before Listing Gaps

A zero-context reviewer restates what a design document proposes before it lists gaps, and a wrong restatement is itself a finding.

Paraphrase-first review asks a reviewer with no prior conversation to restate what a document proposes and how the existing system works. The author then compares that paraphrase with what they meant. The Elephant-Goldfish Model (EGM) runs this as its comprehension stage, and its persona states the rule: "A wrong paraphrase is a finding" (comprehension persona). The persona asks for 2 to 5 sentences on each half.

Why a term scan misses disconnected parts

A term scan lists the words a document uses and never defines. The EGM persona explains the gap. "A list of undefined terms does not find a document whose terms are all defined but whose parts do not connect" (comprehension persona).

A paraphrase must join the parts into one account. When the reader cannot do that for a section, the persona reports the section as a Blocker (comprehension persona). When the reader fills a gap with a guess, the paraphrase reads as fluent and is wrong, and only the author can see that. This reason is inferred. Upstream says only "The author compares it with the intent" (comprehension persona).

The term check still runs after the paraphrase (comprehension persona). The resolution skill also says "Do not contest a comprehension gap." Its reason is "If a fresh reader could not follow the document, the document is missing context" (egm-resolve).

Restrict term checks to project vocabulary

A zero-context reader lacks the project's history but knows general engineering. The EGM persona says "You do not know this project. You do know software." It flags a term only when the term belongs to the project, team, or design and has no definition (comprehension persona).

The commit that added this limit gives no reason for it (commit 36a46ab). The inferred purpose is to keep requests to define ordinary words from burying project gaps.

Keep the paraphrase when there are no findings

The first revision of pull request #170 added the paraphrase. It left the stage on its default route through the synthesizer, the agent that merges reviewer output. Its reviewer warned that "a wrong paraphrase can disappear before the author sees it, particularly when the reviewer reports no findings" (PR #170 review). That reviewer states they "did not reproduce it in a live model run". The inferred risk is that a misread with zero findings looks like a clean pass.

The synthesizer's report template has a reviewer status table and a findings list, and no place for a paraphrase (synthesizer persona). The merged skill spawns the comprehension reviewer directly instead. Its stated reason is "its report keeps only findings, and the author must see the paraphrase". It also says "Keep the paraphrase when there are no findings" (egm-review).

Generalized as an inference, any fan-out with a merge step should route output that is not a finding around the aggregator. A paraphrase field in the aggregator's schema is an alternative EGM does not use.

How it differs from explain-the-change gates

An explain-the-change gate, also called a teach-back gate, tests a different party. There, the author of a code change explains its central mechanism, and a reviewer scores the answer against the diff. That gate measures whether the author understands the change. A paraphrase-first review measures whether the document carries the design to someone who was not present, and the author judges the result. An agent-generated onboarding guide gets a similar signal later, when a new teammate's questions expose stale sections.

Trade-offs

  • The author reads every paraphrase, clean rounds included. EGM reports no measurement of that time.
  • A paraphrase restates only what the document says. It cannot show a requirement the author never wrote down. This limit is an inference; upstream does not state it.
  • The EGM Claude adapter sets model: inherit, so the reader runs on the model of the session that spawns it (adapter). When that matches the drafter's model, the reader can share the drafter's assumptions. This risk is inferred. See when a second model helps in LLM review.
  • EGM publishes no data that paraphrase-first review finds more defects than a term scan. The approving review on PR #170 notes "Live model compliance was not replayed" (PR #170 approval).

Example

EGM covers the no-findings case in a scenario file. Its assertion requires only the word "paraphrase" in the answer, and checks neither the headings nor their content (test scenarios):

- scenario_id: "comprehension_report_keeps_paraphrase"
  description: "Verifies the Comprehension Test report keeps the reviewer's paraphrase."
  eval_type: "deterministic"
  system_prompt:
    skill_file: "skills/egm-review/SKILL.md"
  turns:
    - user_input: "Run only Stage 6 (Comprehension Test) on docs/designs/rate_limit.md. The reviewer reports no findings. What goes in comprehension_report.md?"
      assertions:
        - type: "required_pattern"
          pattern: "(?i)paraphrase"
          message: "The comprehension report must keep the paraphrase, also when there are no findings."

The repository's unit test checks only that each scenario file exists and has the required fields (scenario coverage test). No code at this commit runs the assertion against a model.

Key Takeaways

  • Ask the zero-context reader for a short paraphrase of the proposal and the current system before any gap list.
  • Treat an unparaphrasable section as a Blocker and a wrong paraphrase as a finding, even when the reader reports nothing else.
  • Limit undefined-term flags to project, team, and design vocabulary.
  • Check that your merge step has a field for the paraphrase; if it keeps findings only, send this stage around it.
  • Budget author time to compare every paraphrase with intent, since no upstream data shows the payoff.
Emerging — single recent source Last reviewed: 2026-11-03