Menu
Review and fix academic writing in a LaTeX paper section. Checks sentence-level antipatterns, terminology consistency, and systems-paper conventions.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | paper-review |
| description | Review and fix academic writing in a LaTeX paper section. Checks sentence-level antipatterns, terminology consistency, and systems-paper conventions. |
| when_to_use | Review paper writing, fix academic prose, check terminology consistency, find writing antipatterns |
| argument-hint | ["section-file-path"] |
| allowed-tools | Read Edit Bash(grep *) Bash(wc *) |
Review the LaTeX file at $ARGUMENTS sentence by sentence for academic writing quality. If no argument is given, ask which section to review.
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.---) in paper text. Table --- for N/A is fine.Terminology drift confuses readers more than awkward prose. Run these checks before sentence-level review.
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:
Compound adjectives before nouns need hyphens; standalone uses do not.
| Context | Correct | Wrong |
|---|---|---|
| Before noun | tool-call guardrails | tool call guardrails |
| After verb | operates at the OS level | operates at the OS-level |
| Before noun | cross-event policy | cross event policy |
Check common compounds:
grep -oE '(tool|cross|per|intent|system|application|kernel)[- ](call|event|level)' file.tex | sort | uniq -c
*-level qualifiersMany *-level compounds are redundant. Check if removing -level loses meaning:
| Often redundant | Usually needed |
|---|---|
| system-level (just "system") | OS-level (vs tool-level) |
| kernel-level (just "kernel") | intent-level (vs syscall-level) |
| application-level (just "application") | enforcement-level (classification) |
Test: "system actions" vs "system-level actions" — if both mean the same, drop -level.
Check proper nouns and acronyms:
grep -oE '(eBPF|EBPF|ebpf|BPF)' file.tex | sort | uniq -c
Common issues:
Pick one and stick to it:
Semicolons that join two independent clauses should be rewritten as:
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.
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.
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.
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 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.
| Antipattern | Fix |
|---|---|
| "in order to" | "to" |
| "utilize" / "utilization" | "use" |
| "it is important to note that" | delete or rephrase |
| "it should be noted that" | delete or rephrase |
| "there is/are ... that" | rewrite with real subject |
| "due to the fact that" | "because" |
| "a number of" | "several" or the actual count |
| "in the case of" | "for" or "when" |
| "is able to" | "can" |
| "has the ability to" | "can" |
| "prior to" | "before" |
| "subsequent to" | "after" |
| "with respect to" | "for" or "about" |
| "in terms of" | rephrase directly |
| "the fact that" | delete or use "that" |
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.
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.
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\%.
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 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).
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.
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.
"This", "it", "they" must have an unambiguous antecedent. If unclear, name the referent.
Bad: The engine checks labels and fires rules. This improves compliance.
Good: The engine checks labels and fires rules. This label-checking mechanism improves compliance.
Cut "very", "extremely", "basically", "actually", "really", "significantly" unless they carry measurable meaning. Replace vague intensifiers with numbers.
Bad: significantly reduces latency
Good: reduces latency by 40\%
Max two parenthetical remarks per page. If a parenthetical carries important information, promote it to the main text or cut it.
When replacing semicolons, don't just swap punctuation. Rewrite the sentence to flow:
Before: Labels propagate at fork; the child inherits the parent mask.
After: Labels propagate at fork, so the child inherits the parent mask.
Choose the connector based on the logical relationship:
Before: The DSL has three components. Sources identify objects. Targets are operations. Effects decide outcomes.
After: Each rule in the DSL encodes three components: a source identifies which objects the rule applies to, a target names the operation being constrained, and an effect determines whether the engine blocks, kills, or notifies.
Before: Labels are monotonic.
After: To ensure no history is lost across the session, labels are monotonic.
Before: The engine checks labels and propagates them. This improves safety.
After: The engine checks and propagates labels. This monotonic tracking improves safety.
For each issue found:
L<line>: "<quoted text>"
Problem: <what's wrong>
Fix: "<suggested rewrite>"
End with a summary: total issues by severity, and the top 3 most impactful changes.
After reporting, ask: "Apply fixes? [all / select / none]"
After all fixes, provide: