Rewrite Paper Section

Rewrite A Systems Paper Section

Rewrite the selected body passage while preserving the paper's technical meaning and contribution. Abstract and introduction work belongs to rewrite-abstract-intro.

Do not perform any Git operation. Return the rewritten paper to the caller.

Goals

• Preserve technical meaning and contribution.
• Improve top-down flow and reviewer readability.
• Strengthen architectural clarity and mechanism detail.
• Remove redundancy, vagueness, and weak transitions.
• Keep terminology consistent with the rest of the paper.
• Never invent claims, numbers, mechanisms, results, citations, or architectural components.

Process

1. Diagnose the main narrative, structural, and clarity problems in the current text.
2. Identify the intended role of the section in the paper: motivation, design, mechanism, evaluation, discussion, related work, or another role.
3. Reorganize content if needed so it flows from the high-level point to the concrete mechanism.
4. Rewrite one paragraph or subsection at a time with stronger topic sentences and explicit takeaways.
5. Keep claims calibrated to the paper's actual evidence.
6. If technical details are missing, do not invent them; mark them as % TODO: comments in the LaTeX.

When a standalone request restructures more than one subsection, present the target outline—paragraph roles, moves, splits, merges, and cuts—and obtain explicit user confirmation before rewriting. If an unattended parent workflow already authorizes continuous revision, write the outline to its run log and continue without waiting.

Narrative

Prefer this order within a section or paragraph:

1. state the local problem;
2. explain the key idea;
3. show the mechanism;
4. connect it to the larger architecture or workflow;
5. end with why it matters.

Prefer prose over bullet lists unless the user explicitly asks for an outline.

Constraints

• Preserve LaTeX macros, citation commands (\cite, \ref, \autoref, \Cref), labels, environments, and figure/table references.
• Preserve math notation, variable names, system names, and component names exactly unless the user explicitly asks to revise them.
• Do not introduce new LaTeX packages or environments.
• Avoid vague systems-paper buzzwords such as "novel", "powerful", "flexible", "efficient", or "scalable" unless concrete evidence is nearby.
• Match the tone and terminology already used elsewhere in the paper.
• Do not use prose edits to repair missing experimental evidence.

Output

Report these four parts in order:

1. Main issues — concise diagnosis of narrative, structural, clarity, evidence, or terminology problems.
2. Revision strategy — what was reordered, merged, split, cut, or rewritten and why.
3. Revised LaTeX text — one paste-ready block preserving labels, references, citations, math, and macros.
4. Remaining TODOs or risks — missing evidence, overreaching claims, unclear facts, or % TODO: markers.

When To Push Back

If the requested rewrite would change technical claims, introduce unsupported results or mechanisms, rename established terminology without cause, or create broad churn that the task does not require, state the conflict and propose the smallest valid revision. In an autonomous research pipeline, preserve the ambitious target claim and route missing support back to the evidence program rather than silently weakening it in prose.