Tighten Prose Without Losing Technical Content
Tighten the selected LaTeX for a top systems conference. Prefer local edits over re-architecting the paragraph unless the user asks for broader revision (for that, use rewrite-paper-section).
Do not perform any Git operation. Return the tightened paper to the caller.
Goals
- Reduce wordiness and redundancy.
- Preserve all technical meaning.
- Preserve evidence and the technical qualification a claim needs to stay true. Never add a caveat, and do not preserve one that only concedes weakness.
- Improve sentence rhythm and paragraph focus.
- Keep enough mechanism detail for a systems audience.
Process
- Remove repeated points and filler transitions.
- Replace vague verbs and nouns with more concrete language.
- Shorten long sentences where readability improves.
- Keep the main claim, mechanism, and takeaway of each paragraph intact.
- Do not compress away necessary technical distinctions.
- Demote enumerations: runs of API names, function lists, or config knobs that readers do not need inline belong in a table or appendix, with one sentence in the prose stating what the list shows. More than 2-3 API/symbol names in one paragraph is a signal.
- Check cross-passage duplication: if the selection restates content that already exists elsewhere (a contribution bullet repeating the implementation section, prose repeating an existing table, two paragraphs making the same point), keep the authoritative copy and cut or reference the other.
LaTeX hygiene (minimal churn)
- Preserve citation commands, cross-references, labels, math, and macros unless the user asks to change them.
- Do not introduce new packages, environments, or claims.
- If a trim would require rephrasing a supported claim, keep the safer wording or flag it under "risky trims" instead of guessing.
Output format
Respond with exactly these three parts (use these headings):
- What was making the prose heavy — short diagnosis (repetition, hedge stacking, nominalizations, weak transitions, parallel restatements, etc.).
- Revised LaTeX text — paste-ready block the user can drop into the source.
- Risky trims — bullets naming any further cuts that would likely lose mechanism, distinction, or claim calibration; if none, say "None."
Guardrails
- Do not overshorten technical sections into abstract summaries.
- Do not remove qualifiers that protect claim correctness.
- Do not delete mechanism detail merely to make the paragraph shorter.
- Do not merge distinct technical cases into one vague sentence when the paper needs the split.
Quick self-check before returning
1---2name: tighten-prose-systems-latex3description: Tightens selected LaTeX prose for SOSP/OSDI-style systems papers by cutting redundancy and vague wording while preserving mechanisms, qualifiers, and evidence. Use when the user asks to tighten, shorten, de-verbose, or polish LaTeX without changing technical claims, or when prose feels wordy but the structure is acceptable.4---56# Tighten Prose Without Losing Technical Content78Tighten the **selected** LaTeX for a top systems conference. Prefer local edits over re-architecting the paragraph unless the user asks for broader revision (for that, use `rewrite-paper-section`).910Do not perform any Git operation. Return the tightened paper to the caller.1112## Goals1314- Reduce wordiness and redundancy.15- Preserve all technical meaning.16- Preserve evidence and the technical qualification a claim needs to stay true. Never add a caveat, and do not preserve one that only concedes weakness.17- Improve sentence rhythm and paragraph focus.18- Keep enough mechanism detail for a systems audience.1920## Process21221. Remove repeated points and filler transitions.232. Replace vague verbs and nouns with more concrete language.243. Shorten long sentences where readability improves.254. Keep the main claim, mechanism, and takeaway of each paragraph intact.265. Do not compress away necessary technical distinctions.276. Demote enumerations: runs of API names, function lists, or config knobs that readers do not need inline belong in a table or appendix, with one sentence in the prose stating what the list shows. More than 2-3 API/symbol names in one paragraph is a signal.287. Check cross-passage duplication: if the selection restates content that already exists elsewhere (a contribution bullet repeating the implementation section, prose repeating an existing table, two paragraphs making the same point), keep the authoritative copy and cut or reference the other.2930## LaTeX hygiene (minimal churn)3132- Preserve citation commands, cross-references, labels, math, and macros unless the user asks to change them.33- Do not introduce new packages, environments, or claims.34- If a trim would require rephrasing a supported claim, keep the safer wording or flag it under "risky trims" instead of guessing.3536## Output format3738Respond with exactly these three parts (use these headings):39401. **What was making the prose heavy** — short diagnosis (repetition, hedge stacking, nominalizations, weak transitions, parallel restatements, etc.).412. **Revised LaTeX text** — paste-ready block the user can drop into the source.423. **Risky trims** — bullets naming any further cuts that would likely lose mechanism, distinction, or claim calibration; if none, say "None."4344## Guardrails4546- Do not overshorten technical sections into abstract summaries.47- Do not remove qualifiers that protect claim correctness.48- Do not delete mechanism detail merely to make the paragraph shorter.49- Do not merge distinct technical cases into one vague sentence when the paper needs the split.5051## Quick self-check before returning5253- [ ] Every original technical noun/verb distinction still appears explicitly or is clearly implied without ambiguity.54- [ ] No sentence was added that concedes weakness, apologizes, or declares a limitation.55- [ ] Mechanism steps, interfaces, and invariants are not collapsed into slogans.
eunomia-bpf