菜单
Review a LaTeX paper for argument-level logic, cross-section consistency, and house style. Complements /paper-review (sentence-level style) with whole-paper reasoning checks.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | paper-logic |
| description | Review a LaTeX paper for argument-level logic, cross-section consistency, and house style. Complements /paper-review (sentence-level style) with whole-paper reasoning checks. |
| when_to_use | Check paper logic, argument structure, cross-section consistency, number reconciliation, terminology drift, review whole paper before submission |
| argument-hint | ["paper-dir-or-section-files"] |
| allowed-tools | Read Bash(grep *) Bash(wc *) Bash(ls *) Bash(find *) |
Review the paper at $ARGUMENTS (a directory of sections or specific files)
for argument-level logic and cross-section consistency. If no argument is
given, locate the paper sources (e.g., sections/*.tex plus the main file
containing the abstract) and confirm the file set with the user.
This skill checks the whole-paper layer: does the argument hold together,
do the numbers reconcile, is the terminology stable. For sentence-level prose
(nominalizations, weak openings, word choice), run /paper-review per
section; for applying fixes, run /paper-fix. Do not duplicate their
sentence-level findings. The one exception is section M's mechanical greps
(punctuation, agreement), which enforce house style at whole-paper scope
because they catch drift that per-section review misses.
All examples below are from a fictional paper about a fictional adaptive caching system. They illustrate the shape of each antipattern; never copy them into your report. Every finding must quote the actual paper under review.
Your report is incomplete unless ALL of the following hold. Re-walk the checklists until they do.
[Xn] checked — no findings, plus
one sentence saying what you looked at. Silent skips are not allowed.file:line, a verbatim quote from
the paper under review, a problem statement that names the reasoning
error (not "this is unclear"), and a concrete fix — for prose problems, a
full rewritten sentence, not "consider rephrasing".wording.md) if present. Logic problems are
invisible in a single section — never run this skill on one file alone.Formats below, illustrated with fictional rows. Build them from the actual paper.
One row per recurring concept. The "names used" column exposes drift.
| Concept | Canonical term (per conventions file, if any) | Names actually used (with locations) | First defined at |
|---|---|---|---|
| a unit of admission logic | predicate | predicate (02:§2.2), filter (05:RQ1), policy (05:RQ2) | 02:§2.2 |
A concept with 2+ names, or one name covering 2+ concepts, is a C1 finding. A "first defined at" that comes after a use is a C2 finding.
One row per quantitative claim. Same fact in multiple places = one row with multiple locations; mismatched forms are B1 findings, reader-derivable-only values are B2 findings.
| Fact | Value & form at each location | Locations | Source |
|---|---|---|---|
| hit-rate advantage | "1.8–2.4×" / "15–22 pp" / raw 61 vs 25–34 | intro:¶5, eval:§6.2 text, Tab.2 | only derivable from Tab.2 by reader arithmetic → B2 |
One row per claim in the abstract, intro, or contributions list.
| Promise (quoted, with qualifiers) | Where supported | Qualifier preserved? |
|---|---|---|
| "improves tail latency on production workloads" | §6.4 (12 of 80 workloads, selected for cache sensitivity) | NO — eval scopes to subset, intro doesn't → A4 |
Motivation/empirical/background sections must describe the problem in problem-domain terms. If they classify the world using the system's own mechanisms, the study stops being independent evidence and begs the question.
Bad (in a workload-study section):
These access patterns map directly to our epoch-counters and ghost-list primitives.
Good (same section):
Three recurring patterns emerge: bursty re-reference, scan pollution, and slow drift. All three require admission decisions that depend on history beyond the current request.
…and in Design: "The three patterns identified in §2 reduce to two mechanisms: epoch counters and ghost lists."
How to check: list the design section's mechanism nouns, then grep for each in every section that precedes the design. Each hit in motivation/background is a finding unless it is citing prior work.
Defining a category by reference to the system, then reporting its size as an independent finding, is circular.
Bad:
…the subset of requests that \sys{} can intercept is \emph{trackable}. […] Our study finds that 73% of requests are trackable.
Good:
A request is \emph{trackable} if it carries an object identifier visible at the proxy layer, independent of any particular system. The study finds 73% of requests are trackable, and \sys{} targets exactly this class.
How to check: for every \emph{}d or defined category, ask "does the
definition mention the system?" If yes, every later use of that category's
count as a population is a finding.
If the motivation derives N requirements, the design must visibly consume all N. Count both ends and demand an explicit mapping.
Bad: the motivation summary lists four requirements (history-aware admission, low memory, isolation, observability); the design opens "Two key challenges arise" and resolves them with "three techniques"; isolation and observability map to neither.
Good: a mapping sentence at the start of design: "Requirements R1–R2 raise challenge C1, addressed by epoch counters (§4.1) and ghost lists (§4.2); R3 raises C2, addressed by per-tenant partitions (§4.3); R4 is an implementation property, evaluated in §6.3."
How to check: write out three literal lists (requirements, challenges, components) with locations; draw the mapping; report every orphan on either side as a finding.
Claims scoped to a selected subset must stay scoped in every restatement, and hedging level for the same claim must be identical everywhere.
Bad: eval says "These results suggest that history-aware admission improves tail latency on the 12 cache-sensitive workloads"; conclusion says "\sys{} improves tail latency on production workloads."
Good: the conclusion repeats both the hedge and the scope, or the eval explicitly justifies upgrading the claim.
How to check: for each promise-table row, diff the qualifiers ("suggest", "on the subset", "up to", "in our setting") between the eval sentence and every restatement in abstract, intro, and conclusion. Any dropped qualifier is a finding.
Reserve "cannot", "never", "impossible", and "guarantees" for structural, by-construction facts (a stateless mechanism cannot track cross-event state; tool-call interception cannot observe effects outside the tool boundary). Limitations that are a matter of cost or effort ("an administrator could, with enough work") take "hard", "impractical", or "rarely". Also check the reverse drift: a claim hedged in the body must not strengthen to an absolute in the abstract or intro.
"X has property P; this makes X the natural Y" is an argument, not a fact. Either rebut the obvious objection in place or forward-reference where it is handled.
Bad:
Application developers already know their access patterns. This makes them the natural authors of admission policy.
Good:
Application developers already know their access patterns, so they hold the context that admission policy needs. Letting tenants author policy raises an isolation problem, which we address by bounding each tenant's policy to its own partition (§4.3).
How to check: grep for natural|clearly|obviously|therefore|this makes| this means in intro/motivation; for each hit, ask "what objection would a
hostile reviewer raise here, and is it answered or forward-referenced?"
One paragraph, one claim. How to check: for each intro/motivation paragraph, write its one-line claim; if the line needs "and also", split the paragraph and report it, naming both claims.
Every number in abstract/intro/conclusion must appear verbatim in (or be trivially derivable from a single labeled place in) the evaluation, and the same result must keep one canonical form.
Bad: intro "1.8–2.4×"; eval text "15–22 percentage points" and "2×"; table raw counts — three forms, no anchor sentence connecting them.
Good: one headline form, printed next to its table, reused verbatim: "serves 61 of 90 bursty workloads from cache, 1.8–2.4× the 25–34 of the baselines (Table 2)".
If the headline claim is a ratio or delta, print it beside the table it comes from. How to check: for each abstract/intro number, search the eval for it verbatim; if you had to compute it from table cells, so will the reviewer — that is the finding, and the fix is an anchor sentence.
Every rate names numerator and denominator at first use; exclusions are stated before the rate; subset selection states the rule, counts the remainder, and scopes conclusions (cross-check A4).
Bad: "\sys{} eliminates 70% of avoidable misses. […two paragraphs later…] Cold-start runs are excluded from the miss-rate denominator."
Good: "Of 120 avoidable misses, \sys{} eliminates 84 (70%). The 40 cold-start runs are excluded up front because no admission policy can serve a first access."
How to check: grep for % and rate; for each, write value = N/D with
both numbers named in the same paragraph. Missing N or D, or a post-hoc
exclusion, is a finding.
Significant digits must match measurement reliability; constants from outside the experiment need citations.
Bad: "$0.0314 per query […] At typical cloud egress rates, about $12.47 per workload." (four significant digits against an uncited price assumption)
Good: "about $0.03 per query, versus roughly $12 per workload at list-price cloud egress~\cite{cloudpricing2026}".
How to check: grep for \$[0-9], orders of magnitude, and 3+
significant-digit values; each needs a source (measurement, citation, or
shown derivation).
If the metric definition makes an outcome count favorably for one system and unfavorably for another by construction, disclose it in the sentence that makes the comparison, not paragraphs later.
Bad: praising an ablation's zero wrongful evictions in one paragraph, and only later noting that the metric counts an object re-fetched within the same epoch as "retained" for the ablation but "evicted" for the full system.
Good: "the ablation's zero wrongful evictions partly reflects the metric: without prefetch, re-fetches land in the same epoch and score as retained, while the same objects score as evicted under full \sys{}."
How to check: for every cross-system comparison, re-read the metric definition and ask "could two systems with identical behavior score differently because of how outcomes are labeled?" If yes, the disclosure must be co-located with the comparison.
One concept, one term, throughout — enforce the project's terminology conventions file where present. Flag (a) near-synonym alternation for one referent, (b) one word for two concepts. The term table makes both visible; report each drifting concept as one finding listing all locations.
Every acronym, notation, configuration name, and dataset label is defined before first use — including figure captions and table headers, which readers hit out of order.
Bad: a figure caption says "CG-32 and CG-128"; the CG-$N$ notation is defined two subsections later; "warm-path configurations" is used in one setup paragraph and explained at the end of a different subsection.
How to check: for each notation in the term table, compare
first-definition location against first-use location, treating each figure
caption as used at its \begin{figure} line.
After RQs/sections/figures are renumbered, stale labels and filenames remain.
Bad: figures named rq1_*.pdf are all cited inside the RQ2 subsection,
rq2_*.pdf inside RQ3, and so on — every figure filename is off by one
against the prose that cites it.
How to check: grep includegraphics and \label{, and compare each
filename/label against the number of the subsection citing it. Also check
that anything named in the intro (a benchmark, a dataset, a metric) is
introduced by the same name in its own section.
Setups with multiple models/agents/judges/generators state every role once, in one place, before results — who generates the workload, who runs it, who translates configurations, who judges outcomes, and what software or model backs each role.
Good (one place):
Roles: generator G (model A) produces the traces, translator T (model B) writes the configurations, model C is the system under test (replicated with model D), and the outcome judge runs on the same model as the system under test.
How to check: build the roles table yourself from the eval text. Count how many paragraphs you needed. More than one place = finding; a role you cannot resolve at all = Must fix.
Contribution lists, RQ lists, and itemized claims are grammatically parallel, and each item is a complete sentence. A garbled contribution item is a Must fix: it is the most-read sentence after the abstract.
Bad: "An evaluation on our admission benchmark building on the workload study, external latency and cost benchmarks covering batch and interactive workloads." (no main verb; not parallel)
How to check: read each list item aloud as a standalone sentence; check all items share the same grammatical skeleton ("An X that Y").
Every verification step names the actor and the criterion.
Bad: "We manually corrected samples flagged as requiring double-checking" (flagged by whom, against what rule?); "all of which matched expectations" (whose expectations?).
Good: "the judge flags low-confidence verdicts, and two authors re-label all flagged samples against the written rubric".
How to check: grep flagged|validated|verified|reviewed|matched|confirmed
in methodology text; each hit needs a named actor and criterion.
Numbers repeated in captions must match the prose exactly (count, rounding,
units), and each caption must state the takeaway, not just the axes.
How to check: for every number inside a \caption{}, find its twin in
the body text; flag mismatches and takeaway-free captions.
Adjust paths to the actual file set.
# ~ used as "approximately" (renders as non-breaking space; the "about" vanishes)
grep -n '[ (]~[0-9]' *.tex sections/*.tex
# em-dashes in prose, LaTeX and Unicode forms (house style; table --- for N/A is OK)
grep -n -- '---\|—' sections/*.tex | grep -v '& *--- *&\|--- *\\\\'
# subject-verb agreement: "does" followed by a plural subject
grep -nE 'does [^.?]*\b\w+(ies|s)\b.*\b(improve|prevent|reduce|achieve)' sections/*.tex
# e.g./i.e. punctuation consistency (counts should not both be nonzero)
grep -c 'e\.g\.,' sections/*.tex; grep -c 'e\.g\.[^,]' sections/*.tex
# stale figure numbering and labels (compare against citing subsection)
grep -n 'includegraphics\|\\label{fig:\|\\ref{fig:' sections/*.tex
# semicolons joining clauses (house style; lists OK) — triage each
grep -n '; [a-z]' sections/*.tex
# rates and percentages for the B3 denominator audit
grep -n '[0-9]%\|percent\|rate' sections/*.tex
# unsourced money / magnitude claims for B4
grep -n '\\\$[0-9]\|orders of magnitude' sections/*.tex
Also check by reading (no grep possible):
---) in paper text. Use commas, parentheses, or
restructure. Table cells using --- for "not applicable" are OK.Abstract / Intro: every number traced to the eval (B1/B2); every claim in the promise table with qualifiers (A4); one paragraph = one claim (A6); "we argue/we observe" steps checked for leaps (A5); contribution list checked for parallelism (C5) and 1:1 mapping to sections.
Background / Motivation / Empirical or workload study: no solution vocabulary (A1); categories defined system-independently (A2); the closing summary's requirements recorded for A3; counts here are the canonical source for every later population claim — record them in the number table.
Design: opening consumes all requirements (A3); each mechanism's "why" traces to a motivation finding by explicit reference; terms introduced here checked against the conventions file (C1/C2).
Implementation: numbers (LoC, limits) recorded in the number table; "future work" admissions cross-checked against any capability claimed earlier (A4).
Evaluation: roles stated once (C4); every rate's denominator audited (B3); metric-construction biases disclosed at the comparison (B5); subset selections scoped (A4); figure filenames vs section numbers (C3); captions vs prose (C7); notation defined before the first figure that uses it (C2).
Related work: each contrast sentence states a checkable difference, not adjectives; no claims about your own system that the eval did not support.
Conclusion: pure restatement — any number or scope not identical to the eval's form is a finding (A4/B1).
Fictional findings, at the depth every real finding must match:
[A2][Must] sections/02-motivation.tex:217 "the subset of requests that
\sys{} can intercept is \emph{trackable}"
Problem: the category is defined by what the system can do, then §6.1
("our study finds 73% of requests are trackable") uses its size as a
neutral population — the denominator of the coverage claim is circular.
Fix: "A request is trackable if it carries an object identifier visible at
the proxy layer, independent of mechanism." State the \sys{} alignment
once, separately.
[B3][Must] sections/05-evaluation.tex:514+520 "eliminates 70% of avoidable
misses" … "cold-start runs are excluded from the miss-rate denominator"
Problem: the exclusion that shapes the headline rate is disclosed two
paragraphs after the rate; a reviewer reading linearly recomputes the rate
with different assumptions.
Fix: fold numerator, denominator, and exclusion into the first statement:
"Of 120 avoidable misses, \sys{} eliminates 84 (70%). The 40 cold-start
runs are excluded up front because no admission policy can serve a first
access."
[C3][Should] sections/05-evaluation.tex:91,207,244 figures rq1_pipeline.pdf,
rq1_hitrate.pdf, rq1_breakdown.pdf all cited inside §RQ2
Problem: figure filenames carry a stale RQ numbering (every eval figure is
off by one), signaling unmaintained renumbering to reviewers.
Fix: rename the files to match the current RQ numbers and update the
\includegraphics paths.
findings: N or checked — no findings (looked at: …).