Paper Review

Academic Paper Writing Review & Fix

Review the LaTeX file at $ARGUMENTS sentence by sentence for academic writing quality. If no argument is given, ask which section to review.

Review process

1. Read the entire file
2. Check terminology consistency (Section T below) FIRST
3. For each paragraph, analyze every sentence against the checklist below
4. Report issues grouped by severity: Must fix (clarity/logic errors), Should fix (antipatterns), Consider (style preferences)
5. For each issue, give the line number, quote the problematic text, explain the problem, and suggest a concrete rewrite
6. Ask user which fixes to apply, then use Edit tool

Critical rules (for fixes)

• NEVER delete design decisions or technical content. Compression means better prose, not less information.
• NEVER change the meaning of a sentence. If unsure, ask.
• NEVER remove a scope-bearing hedge (suggest ... on the selected subset, in our setting, up to): it protects the claim from outrunning its evidence (/paper-logic A4/A5). Only collapse stacked hedges down to one.
• Always diff-check after multiple edits to ensure no content was lost.
• No em-dashes (---) in paper text. Table --- for N/A is fine.
• No semicolons joining independent clauses. Use periods, conjunctions, or causal connectors.
• Why before what: every design decision states its motivation first.
• Example before abstraction: show a concrete case, then generalize.

Section T: Terminology Consistency (NEW - check FIRST)

Terminology drift confuses readers more than awkward prose. Run these checks before sentence-level review.

T1: Same concept, same term

Grep for near-synonyms. If the same concept uses multiple terms, unify to one.

grep -oE '(policy|rule|constraint|directive)' file.tex | sort | uniq -c

Common drift pairs to check:

• policy / rule / constraint / directive
• harness / runtime / framework
• enforce / check / validate / verify
• block / deny / prevent / reject

T2: Compound adjective hyphenation

Compound adjectives before nouns need hyphens; standalone uses do not.

Check common compounds:

grep -oE '(tool|cross|per|intent|system|application|kernel)[- ](call|event|level)' file.tex | sort | uniq -c

T3: Redundant *-level qualifiers

Many *-level compounds are redundant. Check if removing -level loses meaning:

Test: "system actions" vs "system-level actions" — if both mean the same, drop -level.

T4: Capitalization consistency

Check proper nouns and acronyms:

grep -oE '(eBPF|EBPF|ebpf|BPF)' file.tex | sort | uniq -c

Common issues:

• eBPF (not EBPF, ebpf)
• GitHub (not Github, github)
• macOS (not MacOS, macos)

T5: Spelling variants

Pick one and stick to it:

• runtime vs run-time
• pre-defined vs predefined
• sub-agent vs subagent

Sentence-level antipatterns

Semicolons joining independent clauses

Semicolons that join two independent clauses should be rewritten as:

• Two sentences (period)
• One sentence with a conjunction (", and", ", but", ", so")
• One sentence with a causal connector ("because", "since", "therefore") Semicolons ARE acceptable inside parenthetical lists.

Bad: The engine propagates labels; rules fire at each event. Good: The engine propagates labels, and rules fire at each event. Good: Because the engine propagates labels, rules fire at each event.

Note-like prose (short declarative sentences strung together)

Academic prose uses causal connectors, subordinate clauses, and flowing sentences. Short declarative sentences read like bullet points, not a paper.

Bad: Labels propagate at fork. The child inherits the parent mask. Rules check the mask at each event. Good: Labels propagate at fork, so the child inherits the parent mask and rules can check it at each event.

Tie-breaker: this rule targets runs of three or more short declaratives. A pair of sentences produced by splitting an overlong sentence (e.g., to fix subject-verb separation) is fine — do not re-merge it.

Missing "why" before "what"

Every design decision must explain its motivation before describing the mechanism. Readers need to understand the problem before the solution.

Bad: We use monotonic labels. Labels are never removed once added. Good: To ensure no history is lost across the session, labels are monotonic: propagation adds labels but never removes them.

Em-dashes (---)

Never use em-dashes in paper text. Use commas, parentheses, semicolons (in lists), or restructure the sentence. Table cells using --- for "not applicable" are acceptable.

Colons before non-lists

Colons may introduce lists, definitions, and elaborations of the claim just made (labels are monotonic: propagation adds labels but never removes them). Avoid colons that splice two clauses with no claim-elaboration relationship.

Bad: The engine uses eBPF: the verifier imposes a stack limit. (the second clause does not elaborate the first; use "so" or two sentences) Good: The engine has three effects: notify (observe only), block (pre-operation denial), and kill (process termination). Good: Labels are monotonic: propagation adds labels but never removes them.

Word-level antipatterns

Sentence structure antipatterns

Weak openings

Avoid starting sentences with "It is", "There is/are", "This is". Use a concrete subject.

Bad: There are three hooks that the engine attaches to. Good: The engine attaches to three hooks.

Subject-verb separation (Gopen & Swan)

Keep the grammatical subject within 7 words of its verb. Long intervening clauses force the reader to hold the subject in memory.

Bad: The protocol, which was developed over three years by a distributed team working across four time zones, handles failover. Good: The protocol handles failover. A distributed team developed it over three years across four time zones.

Topic position / stress position (Gopen & Swan)

Put old/known information at the sentence start (backward link). Put the new, emphatic information at the sentence end (stress position).

Bad: A 40\% reduction in latency results from label caching. Good: Label caching reduces latency by 40\%.

Dangling modifiers

The modifier must attach to the grammatical subject.

Bad: Using eBPF, the policy is enforced at the kernel level. Good: Using eBPF, the engine enforces the policy at the kernel level.

Passive voice (when the agent matters)

Passive is fine for methodology when the actor is obvious and irrelevant ("traces were collected"), but use active voice when the actor matters for understanding.

Bad: Labels are propagated by the engine at each system event. Good: The engine propagates labels at each system event.

Exception: verification and judgment steps ("samples were verified", "results were reviewed") must name the actor and criterion even in methodology — an agentless verification claim is unfalsifiable (see /paper-logic C6).

Nominalizations (turning verbs into nouns)

Use the verb form when possible. "make assumption" -> "assume"; "perform analysis" -> "analyze"; "is a requirement" -> "requires".

Bad: The propagation of labels occurs at fork events. Good: Labels propagate at fork events.

Redundant hedging

One hedge per claim is enough. Remove stacked hedges. Do not hedge your own measurements or established facts.

Bad: This may potentially suggest that the overhead could possibly be acceptable. Good: This suggests the overhead is acceptable.

Protected hedges — never remove: a hedge that carries claim scope (suggest ... on the 12 selected workloads, in our setting, up to) is protecting the claim from outrunning its evidence. Removing it creates a logic error worse than the wordiness (see /paper-logic A4/A5). Remove the stack, keep one scope-bearing hedge.