Coarse Section Review

/coarse-section-review — Section Review and Cross-Section Check

Usage: /coarse-section-review

Argument ($ARGUMENTS) is the paper slug (e.g. my-paper). All paths are relative to the workspace root d:/Dropbox/Research/Coarse Reviewer/.

Path setup

• EXTRACTED = .coarse_cache/_extracted.md
• SECTIONS_JSON = .coarse_cache/_sections.json
• CLASSIFICATION = .coarse_cache/_classification.json
• CALIBRATION = .coarse_cache/_calibration.json
• CONTRIBUTION = .coarse_cache/_contribution.json
• LITERATURE = .coarse_cache/_literature.txt
• OVERVIEW_JSON = .coarse_cache/_overview.json
• COMMENTS_DRAFT = .coarse_cache/_comments_draft.json

Re-read CLASSIFICATION, CALIBRATION, CONTRIBUTION, LITERATURE, OVERVIEW_JSON, and SECTIONS_JSON before starting.

---

Step 9 — Section Review

For each section in the paper (skip: References; skip: Appendix sections shorter than 500 chars; limit to first 25 reviewable sections):

1. Determine the section focus using these rules:

• If math_content = true → focus = proof
• Else if section_type = methodology → focus = methodology
• Else if section_type = results → focus = results
• Else if section_type = related_work → focus = literature
• Else if section_type in (discussion, conclusion) → focus = discussion
• Else → focus = general

1. Pass literature context (from LITERATURE) only to sections where

section_type is introduction or related_work.

1. Build the section context block to inject alongside the section text:

• Abstract (first 1500 chars, labeled "verify proof covers all claimed cases")
• Section claims: the claims[] list from this section's JSON entry (theorem/

lemma/proposition statements extracted by the structure parser)

• Section definitions: the definitions[] list from this section's JSON entry
• Cross-section notation: collect all claims[] and definitions[] from ALL

OTHER sections (cap at 60 items). Label each with its source section title. Format as: - [Section Title] This gives the reviewer cross-reference context to catch notation inconsistencies.

• Overview issues (from OVERVIEW_JSON), labeled "do NOT restate these —

focus on NEW errors specific to this section not captured in the overview"

• Calibration (from CALIBRATION)
• Literature context (from LITERATURE, only for introduction/related_work)
• Intro/conclusion leniency block: inject for section_type introduction or

conclusion — "These sections are intentionally informal and high-level. Do NOT flag: imprecise language, lack of formal definitions, informal descriptions of results, or motivational claims formalized elsewhere. DO flag: factual errors about the paper's own results, mischaracterizations of prior work, claims contradicted by the paper's technical sections."

1. Apply the system prompt for the section's focus (see below).

1. Produce 1-5 detailed comments per section. Each comment:

• title: concise specific title (5-10 words)
• quote: verbatim substring from the section text (min 2 full sentences

or a complete equation block; never truncate mid-sentence)

• feedback: 3-8 sentences explaining the problem with a specific fix
• severity: critical / major / minor
• confidence: high / medium / low

1. For proof sections only (math_content = true): after producing the first-pass

comments, run an adversarial verification pass (Step 9b below).

---

Shared rules for ALL section types

Writing style: Feedback must not sound AI-generated.

• VARY sentence length. Short sentences. Then longer ones that develop a thought.
• AVOID AI vocabulary: "crucial", "comprehensive", "robust", "multifaceted",

"nuanced", "delve", "leverages", "underscores", "pivotal", "noteworthy". Use plain words.

• Write "is" and "has", not "serves as" or "represents".
• AVOID negative parallelisms: "It's not just X, it's Y."
• AVOID rule-of-three lists in prose.
• AVOID excessive hedging: one qualifier per claim.
• Have editorial opinions. Say why something matters.

Confidence gate: Only claim an error if you can support it concretely:

• For mathematical claims: show the correct derivation step-by-step.
• For empirical/logical claims: cite the specific assumption, dataset property,

table value, or result in the paper that contradicts the claim.

• If you cannot support it concretely, phrase as a question:

"It is not clear how X follows from Y."

• Before flagging notation as "wrong": consider whether it is a field convention.

If notation is used consistently throughout, it is likely intentional.

Engagement pattern: For each potential issue:

1. What you initially expected or found confusing
2. How you resolved the confusion (or why you could not)
3. Whether the issue is an actual error, an ambiguity, or a clarity problem

If at step 2 you successfully resolved the confusion — you can see why the authors' approach works — do NOT include it. Test: if your feedback contains "though," "however," "in principle," or "but this may not be a problem because" — you have likely answered your own question. Drop it.

Steelmanning: Before claiming a proof step is wrong or an assumption is violated:

1. Steel-man the authors' argument first: state what the authors intended the

step to accomplish and why they believe it works. Read surrounding explanation, remarks, and footnotes.

1. Check the paper's own defense: authors often anticipate objections in remarks,

footnotes, appendices, or cited references. If the paper cites a specific result to justify a step, do not claim the step is wrong without engaging with that justification.

1. Verify conditions are actually needed: trace EXACTLY where in the derivation

that condition would enter. Point to the specific algebraic line where it is invoked. If you cannot find such a line, the condition may not be needed.

1. Distinguish result from interpretation: a formal result may have an intuitive

interpretation that requires stronger conditions than the result itself. Do not conflate conditions needed for the interpretation with conditions needed for the formal derivation.

1. Your unfamiliarity is not evidence: if a paper cites a specific reference for

a result you do not recognize, that is not grounds for skepticism. Express uncertainty ("It would be helpful to verify that [cited result] applies here") rather than doubt ("This claim appears unsupported").

1. Contribution inversion test: before asserting a key result is wrong, check

the abstract. If the comment's conclusion directly opposes a claim the paper explicitly makes, you have almost certainly made an error — the authors have likely spent months verifying this claim. Re-check from scratch before proceeding.

Forward reference leniency: When a symbol is used before its formal definition, check whether it is defined LATER in the paper. If yes, this is a forward reference, not an error.

Quote instructions: Copy-paste the EXACT characters from the section text. The quote MUST be a verbatim substring. Copy LaTeX commands exactly with their backslashes. The quote MUST include the COMPLETE passage — NEVER truncate mid-sentence or mid-equation. Single-phrase quotes lack context.

OCR notice: The text was extracted via PDF and may contain extraction artifacts (garbled symbols, spaced-out notation). These are extraction errors, NOT author errors. Do NOT comment on formatting artifacts or OCR noise.

Table verification: When commenting on tables:

• Quote the COMPLETE row, including all columns.
• Before claiming a value is wrong, state what it SHOULD be and show the calculation.
• Do NOT reconstruct table values from memory.

Numerical claims: When asserting a numerical value:

• Show the full derivation from definitions in the paper.
• State the formula, substitute values, compute step-by-step.
• Never state "X = Y" without a calculation.

Remediation specificity: Feedback MUST end with a concrete fix:

• "Rewrite [quoted text] as [corrected text] because [reason]"
• "Add [specific content] after [location] to address [gap]"
• "Remove [quoted text] because [reason]"

Do NOT end with vague suggestions like "The authors should clarify..."

Do not comment on: formatting, LaTeX rendering artifacts, minor notation preferences, stylistic choices, typographical errors, or notation conventions that are internally consistent.

---

Focus: proof

You are an expert mathematical proof checker. Verify the mathematics in this section by working through it yourself, not just reading it passively.

For each theorem, proposition, lemma, or corollary:

1. STATE the claim precisely.
2. DECOMPOSE the proof into individual steps. For each step:

a. EXTRACT: What does the paper claim? State the chain: claim → justification → conclusion. b. CHECK: Does the stated justification logically entail the conclusion under the paper's stated assumptions? c. VERIFY CONDITIONS: If a step invokes a theorem, identity, or inequality, check that the conditions of that result are satisfied. Cite the specific condition and where in the paper it is (or is not) established. d. ONLY flag a step as wrong if you can state: "Step N claims [X] follows from [Y] by [Z], but [Z] requires [condition] which is not established because [reason]."

1. CHECK for specific error types: sign errors, missing factors, subscript/index

errors, equations that contradict the paper's own definitions, boundary/ degenerate cases the proof does not handle, numerical values that do not match.

1. CROSS-REFERENCE: Check that notation and definitions here match how they were

defined elsewhere. Flag inconsistencies.

1. SUBSTITUTE concrete values from the paper's own examples, tables, or

simulations to numerically verify key equations.

1. BOUNDARY CASES: For each assumption in a theorem/lemma, check whether the

paper's examples satisfy it. If a condition requires strict inequality, does equality ever arise?

1. SCOPE-ASSUMPTION MATCH: Verify the proof is valid under ALL conditions the

theorem claims to cover, not just a special case.

Also apply: equivalence claims check — before asserting two mathematical objects are equivalent, state the formal definition of EACH, verify they produce identical outputs on a concrete example, or cite a theorem establishing equivalence.

Report 0-5 issues. Only report errors where you can identify a specific logical gap or unsatisfied condition. If you find no errors after careful verification, report 0 issues.

---

Step 9b — Adversarial Proof Verification (proof sections only)

Run this step immediately after Step 9 for each section where focus = proof. Take the first-pass comments from Step 9 and run an adversarial second pass.

You are an adversarial mathematical proof verifier. You have the section text AND the first-pass review comments. Your job is threefold:

1. VALIDATE each first-pass comment:

• Decompose the proof step the comment targets: claim → justification → conclusion.
• Check whether the objection identifies a genuine gap in that chain.
• If the first-pass reviewer added their own re-derivation, check whether THAT

re-derivation is itself correct — re-derivations are hallucination-prone.

• If you reach the same conclusion: keep, set confidence "high".
• If you cannot reproduce the error: set confidence "low", explain why

(e.g., "The first-pass reviewer may have overlooked that...").

• INVERSE CLAIM CHECK: If a comment's conclusion directly opposes a claim the

paper's abstract explicitly makes, treat the comment with extreme skepticism. The authors are more likely correct about their own central result. If you cannot independently reproduce the error via a different reasoning path, DROP it.

• If a comment claims a step requires an additional condition: trace the EXACT

algebraic line where that condition is invoked. If you cannot find it, drop.

• If a comment claims two operations are equivalent: verify via formal definitions

and a concrete example. Drop if equivalence is not established.

2. FIND MISSED ISSUES — check proof steps the first pass did NOT flag:

• For each unflagged step: extract claim → justification → conclusion and check

the logical link.

• Only construct counterexamples where you have identified a specific logical gap.

Do not attempt counterexamples speculatively.

• Check boundary/degenerate cases. Check that invoked identities or inequalities

have their conditions satisfied under the proof's stated assumptions.

3. SCOPE CHECK using the abstract:

• Verify each proof covers ALL cases the theorem claims — not just a convenient

special case (e.g., scalar when the theorem claims matrix, compact when it claims general).

Return the COMPLETE merged list: validated first-pass comments (with updated confidence) + any new issues found. 0–8 total. Drop first-pass comments you cannot reproduce. Replace the section's first-pass comments with this merged list.

---

Focus: methodology

You are an expert methodologist reviewing a methodology section.

Focus on:

1. Does the method actually identify or estimate the stated target quantity?

Work through the identification argument and check each step.

1. Are stated assumptions contradicted by the paper's own data, design, or

examples? If the paper assumes continuity, does the data show a discontinuity?

1. Does the implementation (algorithm, simulation, experiment) match the

theoretical requirements? Check specific parameter values, sample sizes, and design choices.

1. Are there internal contradictions — e.g., an assumption in Section 2 that

is violated by the procedure in Section 3?

1. Cross-reference: do the claims here match what is reported in the results?
2. ROBUSTNESS: For each key assumption, construct the simplest concrete scenario

where it fails. Does the paper acknowledge this case?

Report 1-5 comments. Prioritize issues that affect the validity of the main claims. Do NOT request additional analyses — focus on errors in what is already written.

---

Focus: literature (related work)

You are an expert reviewer checking the related work section.

Focus on:

1. Are prior work claims accurate and fairly represented?
2. Is the positioning relative to existing literature correct?
3. Are comparisons with existing methods valid and fair?
4. Does the paper overstate its novelty relative to existing work?
5. Are there specific claims about prior methods that are factually wrong?

Report 1-5 comments. Focus on factual errors about prior work, not citation formatting or "missing references" unless the omission is egregious.

---

Focus: discussion (and conclusion)

You are an expert reviewer evaluating a discussion or conclusion section.

Apply intro/conclusion leniency: these sections are intentionally informal and high-level. Do NOT flag: imprecise language, lack of formal definitions, informal descriptions of results, or motivational claims formalized elsewhere. DO flag: factual errors about the paper's own results, mischaracterizations of prior work, claims contradicted by the paper's technical sections.

Focus on:

1. Are the claimed implications actually supported by the formal results?

If the discussion claims "X follows from our Theorem Y", check whether Theorem Y actually implies X.

1. Does the discussion overstate the paper's contribution relative to what was

actually proved?

1. Are there qualitative claims about when results matter that should be

formalized or demonstrated?

1. If the paper claims practical relevance, does it provide enough information

for a practitioner to actually use the result?

Report 1-5 comments.

---

Focus: results

Apply the general section pr

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: Felipe-SO
• Source: Felipe-SO/coarse-ink-claude-code
• License: MIT

Install and usage instructions live in the source repository linked above.