| name | paper-writing-style |
| description | Review and fix sentence-level writing quality in LaTeX paper sections. Checks punctuation, sentence structure, word choice, and systems-paper prose conventions. For terminology/jargon/concept/information-flow issues, use check-terminology-infoflow instead. |
| allowed-tools | Read Edit Bash(grep *) Bash(wc *) |
Academic Paper Writing Review & Fix (Sentence-Level)
Review the LaTeX file at $ARGUMENTS sentence by sentence for academic writing quality. If no argument is given, ask which section to review.
Do not perform any Git operation. Return paper and review changes to the caller.
Scope: This skill covers sentence-level prose mechanics (punctuation, structure, word choice, flow patterns). For terminology consistency, invented jargon, cross-section concept coherence, and information flow, use the check-terminology-infoflow skill instead.
Review process
- Read the entire file (or specified section)
- For each paragraph, analyze every sentence against the checklist below
- Report issues grouped by severity: Must fix (clarity/logic errors), Should fix (antipatterns), Consider (style preferences)
- For each issue, give the line number, quote the problematic text, explain the problem, and suggest a concrete rewrite
- Apply the fixes directly with the Edit tool — Must fix first, then Should fix, then evaluate each Consider item and apply the ones that improve the text (note rejected ones with a one-line reason). Do not ask the user which fixes to apply, and do not silently discard anything below Must fix. Exception: when invoked read-only as a review subagent (e.g. from iter-refine-writing), report findings only and make no edits — the calling agent applies them.
Editing discipline
- Minimal targeted changes only — never rewrite, restructure, or delete existing content unless explicitly asked.
- When updating numbers/data, do NOT touch prose wording.
- Preserve the user's exact wording and meaning. Do not soften, strengthen, or "fix grammar" unless asked; flag suggestions instead of applying them.
- Avoid absolutist words like "cannot", "impossible", "never" unless structurally true.
- Convert unnecessary negations to positive statements. Prefer direct assertions over "not X" or "rather than X" patterns. "does not type-check" → "is a type error"; "not how many places" → "but misses how many places". Keep negations only for genuine contrast ("a type error, not a runtime failure") or explicit exclusion.
- Deep pass on first attempt — do thorough review (not just mechanical/surface fixes). Shallow first passes waste user time.
- Verify before claiming done — recompile LaTeX, check it builds. Do not claim "fixed" until verified.
Critical rules (for fixes)
- System name via
\sys macro only. Never hardcode the system name in prose — always use \sys. Flag any hardcoded system name as Must-fix.
- NEVER delete design decisions or technical content. Compression means better prose, not less information.
- NEVER change the meaning of a sentence. If unsure, ask.
- Always diff-check after multiple edits to ensure no content was lost.
Punctuation rules
No em-dashes (---)
Never use em-dashes in paper text. Use commas, parentheses, or restructure the sentence. Table cells using --- for "not applicable" are acceptable.
No semicolons joining independent clauses
Rewrite 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 and numbered enumerations.
Bad: The engine propagates labels; rules fire at each event.
Good: The engine propagates labels, and rules fire at each event.
Colons (avoid unless introducing a numbered list)
Only use colons for introducing a numbered list with explicit markers like (1), (2), (3).
Never use colons for unlabeled lists, claim: evidence, setup: result, or observation: explanation patterns. Use causal connectors or split into two sentences.
Bad: Optimization spans three layers: source, LLVM, and JIT. (unlabeled list)
Good: The framework addresses three goals: (1) crash isolation, (2) bounded action spaces, and (3) multi-layer feedback. (numbered list)
Parentheticals (avoid unless necessary)
Only use parentheses for: (1) citations/references (Figure 1, Table 2), (2) abbreviations on first use. Never for lists or explanations.
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.
NOT weak openings — do not change:
- "The key observation is that..." — standard academic signal phrase for core insight
- "The key idea is that..." — same
- "The main contribution is..." — same
- Signal phrases that frame the claim are not "It is" filler
Transitional words (preserve)
Do NOT remove or change transitional connectors like "Yet", "However", "Nevertheless", "Moreover", "Furthermore" at sentence starts. These are standard academic transitions that signal logical relationships between paragraphs or ideas.
Acceptable: Yet the programming model is fragmented.
Acceptable: The programming model, however, is fragmented.
Both forms are correct. Do not convert one to the other unless there is a specific structural reason (e.g., paragraph-initial "Yet" vs mid-sentence "however" for emphasis).
Subject-verb separation (Gopen & Swan)
Keep the grammatical subject within 7 words of its verb.
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.
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 ("traces were collected"), but use active voice when the actor matters.
Bad: Labels are propagated by the engine at each system event.
Good: The engine propagates labels at each system event.
Note-like prose (3+ short declaratives in a row)
Academic prose uses causal connectors, subordinate clauses, and flowing sentences. Short declarative sentences strung together read like bullet points.
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: targets runs of three or more short declaratives. A pair of sentences from splitting an overlong sentence is fine.
No bullet points or lists in narrative prose
Convert lists to flowing paragraphs with causal connectors.
Exceptions: contribution lists, algorithm pseudocode, comparison tables, explicit enumerations referenced later.
Subject first
Start important sentences with a concrete actor or object. Prefer "The profiler ranks...", "Operation stacks group..." over vague starts like "This shows...", "These checks...".
Use explicit author subjects when appropriate
For author choices: "We compare...", "We evaluate...", "We find..."
For mechanism behavior: "The profiler ranks...", "The operation stack groups..."
Vague referents
"This", "it", "they" must have an unambiguous antecedent. If unclear, name the referent explicitly.
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.
Bad: We test three configurations. It shows that caching helps.
Good: We test three configurations. The comparison shows that caching helps.
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\%.
"Label caching" is already known from context; "40%" is the new finding that belongs at the stress position.
Too many small experiments
Evaluation sections should organize around a small number of claim-facing research questions (usually 3-4), not many small script-shaped experiments. If the prose enumerates many tiny checks, consolidate.
Bad: We run R320 for ranking, R325 for depth, R358 for boundaries, R366 for fields, and R400 for suitability.
Good: The evaluation asks whether operation stacks improve localization and reduce inspection work. It then explains which stack fields drive those gains.
Word-level antipatterns
| 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" |
Nominalizations
Use the verb form. "make assumption" → "assume"; "perform analysis" → "analyze"; "is a requirement" → "requires".
Unnecessary adverbs
Cut "very", "extremely", "basically", "actually", "really", "significantly" unless they carry measurable meaning. Replace vague intensifiers with numbers.
Claim & evidence patterns
Claim before evidence
State what the numbers mean before giving the numbers. The reader should know why the data matters before seeing the data.
Bad: 217 (36%) have one clause. 231 (38%) have two. (data dump)
Good: Most policies are structurally simple: 74% have at most two clauses.
Paper, not project report
Reject prose that reads like a status update, experiment diary, artifact index, TODO list, or negative result. A paper section presents only final positive results and tells the reader what claim matters and why the evidence supports it.
Evidence without a subject
Evidence sentences need an actor or object before the measurement.
Bad: The generated table shows that operation stacks reduce inspection work.
Good: Operation stacks reduce inspection work, as the ranking experiment shows.
Hedging rules
Redundant hedging
One hedge per claim is enough. Remove stacked hedges. Do not hedge your own measurements.
Bad: This may potentially suggest that the overhead could possibly be acceptable.
Good: This suggests the overhead is acceptable.
Self-attacking sentences and overclaims (delete or downgrade)
Delete sentences that weaken the contribution, self-attack, or apologize. Downgrade overclaims: "exactly nested intervals" → "we model as nested intervals"; "established" → "demonstrates"; "equal quality" → "similar".
Bad (self-attack — tells reviewer how to attack):
"A stronger study would mine real eBPF bugs from revision histories." — delete."these numbers are illustrative rather than statistically robust" — delete. Numbers too weak to state plainly are not paper evidence: they stay in the repository and their RQ needs a real experiment, so never delete the caveat and keep the weak number as a hard claim.
Quick self-edit pass (apply to every sentence)
- Can I delete the first word/phrase without losing meaning?
- Is a verb hidden inside a noun? Undo the nominalization.
- Is the subject more than 7 words from its verb?
- Does the sentence end on the most important new information?
- Does the sentence start with something the reader already knows?
- Is an adverb doing the work a number should do?
- Am I hedging my own result?
- Does "this/it/that" have a clear antecedent? If not, name the referent.
Fix priority
- Clarity: dangling modifiers, vague referents, missing motivation
- Structure: semicolons, note-like prose, weak openings, passive voice, nominalizations
- Word choice: verbose phrases from the antipattern table
- Punctuation: colons before non-lists, em-dashes
Output format
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 all fixes, recompile and verify. Provide:
- Number of sentences changed
- Categories of changes made
- Any sentences flagged but NOT changed (and why)
