MobiSys Writing Style
Use this when revising the main paper. A MobiSys paper needs a compact statement of the
on-device problem, the system that solves it, and the measurements that prove it — in the
12-page double-column body.
Revision rules
- Put the mobile-system contribution on the first page: the on-device pain, why current
systems fail on the device, the mechanism, and the measured payoff.
- Name the device budget explicitly. MobiSys reviewers are sensitive to hidden compute,
energy, latency, memory, and thermal assumptions.
- Pair every major claim with a measurement on real hardware, a design argument, or a
reproducibility detail — never a superlative.
- Use the 12-page body for the system's spine; move long protocols, extra device sweeps, and
extended ablations to the appendix without making the main paper unintelligible.
- Avoid overclaiming wins when the distribution is unreported or the gain is inside run-to-run
spread.
- Maintain double-blind style in self-citations, prior-system references, acknowledgements,
funding, screenshots, and artifact descriptions.
System-presentation discipline
- State the operating point: the device, the workload, and the budget the system respects.
A latency number without its device and workload is not interpretable.
- Give each design decision a why-on-the-device justification; MobiSys readers audit
whether a choice is forced by the mobile constraint or merely convenient.
- Report costs as distributions — p50/p95 latency, energy-per-operation, memory footprint
— not single "up to N×" peaks.
- Separate measured from estimated: an energy figure from a power monitor and an energy
figure from a model are different claims and must be labeled so.
- Keep the accuracy/quality trade-off honest: a system that is faster or cooler at a cost must
state the cost in the same breath.
Sentence-level rewrites
| Draft pattern |
MobiSys-safe rewrite |
| "Our system significantly outperforms..." |
"cuts p95 latency from X ms to Y ms on over N runs" |
| "Runs efficiently on mobile devices..." |
"holds 30 fps within a 3 W budget on , App. A" |
| "Saves substantial energy..." |
"reduces energy-per-frame by X mJ (p50), measured on " |
| "Achieves real-time performance..." |
Claim scoped to the device, workload, and thermal state tested |
Vignette: compressing into twelve double-column pages
A draft with a runtime design, five device studies, and a sprawling background section: keep
the design, one decision-critical figure (the latency-under-load curve) and one budget figure
(energy-per-frame), and the accuracy-cost table; compress background into the specific failures
current systems show on the device; move three device sweeps and the full protocol to the
appendix with forward references. The test of a good cut: a systems reviewer should
reconstruct the whole system and its evidence without opening the supplement.
Output format
[Writing diagnosis] clear / under-measured / overclaimed / overloaded
[First-page fix] <new mobile-system framing>
[Claim discipline] <claim -> measurement/design/limitation>
[Compression cuts] <move/delete/merge>
[Anonymity edits] <phrases, screenshots, or repo strings to rewrite>
Source: brycewang-stanford/Awesome-Journal-Skills → MobiSys-Skills/skills/mobisys-writing-style/SKILL.md
1---2name: mobisys-writing-style3description: Use when revising a MobiSys paper for a mobile-systems first page, the pain → system-design → on-device-evidence arc, 12-page double-column compression, double-blind wording, and claims disciplined by measured latency, energy, memory, and thermal budgets rather than superlatives, so the draft survives systems-and-services reviewers.4---567# MobiSys Writing Style89Use this when revising the main paper. A MobiSys paper needs a compact statement of the10on-device problem, the system that solves it, and the measurements that prove it — in the1112-page double-column body.1213## Revision rules1415- Put the mobile-system contribution on the first page: the on-device pain, why current16 systems fail *on the device*, the mechanism, and the measured payoff.17- Name the device budget explicitly. MobiSys reviewers are sensitive to hidden compute,18 energy, latency, memory, and thermal assumptions.19- Pair every major claim with a measurement on real hardware, a design argument, or a20 reproducibility detail — never a superlative.21- Use the 12-page body for the system's spine; move long protocols, extra device sweeps, and22 extended ablations to the appendix without making the main paper unintelligible.23- Avoid overclaiming wins when the distribution is unreported or the gain is inside run-to-run24 spread.25- Maintain double-blind style in self-citations, prior-system references, acknowledgements,26 funding, screenshots, and artifact descriptions.2728## System-presentation discipline2930- State the **operating point**: the device, the workload, and the budget the system respects.31 A latency number without its device and workload is not interpretable.32- Give each design decision a **why-on-the-device** justification; MobiSys readers audit33 whether a choice is forced by the mobile constraint or merely convenient.34- Report costs as **distributions** — p50/p95 latency, energy-per-operation, memory footprint35 — not single "up to N×" peaks.36- Separate **measured** from **estimated**: an energy figure from a power monitor and an energy37 figure from a model are different claims and must be labeled so.38- Keep the accuracy/quality trade-off honest: a system that is faster or cooler at a cost must39 state the cost in the same breath.4041## Sentence-level rewrites4243| Draft pattern | MobiSys-safe rewrite |44|---|---|45| "Our system significantly outperforms..." | "cuts p95 latency from X ms to Y ms on <device> over N runs" |46| "Runs efficiently on mobile devices..." | "holds 30 fps within a 3 W budget on <device>, App. A" |47| "Saves substantial energy..." | "reduces energy-per-frame by X mJ (p50), measured on <monitor>" |48| "Achieves real-time performance..." | Claim scoped to the device, workload, and thermal state tested |4950## Vignette: compressing into twelve double-column pages5152A draft with a runtime design, five device studies, and a sprawling background section: keep53the design, one decision-critical figure (the latency-under-load curve) and one budget figure54(energy-per-frame), and the accuracy-cost table; compress background into the specific failures55current systems show on the device; move three device sweeps and the full protocol to the56appendix with forward references. The test of a good cut: a systems reviewer should57reconstruct the whole system and its evidence without opening the supplement.5859## Output format6061```text62[Writing diagnosis] clear / under-measured / overclaimed / overloaded63[First-page fix] <new mobile-system framing>64[Claim discipline] <claim -> measurement/design/limitation>65[Compression cuts] <move/delete/merge>66[Anonymity edits] <phrases, screenshots, or repo strings to rewrite>67```6869---7071**Source:** [`brycewang-stanford/Awesome-Journal-Skills`](https://github.com/brycewang-stanford/Awesome-Journal-Skills) → `MobiSys-Skills/skills/mobisys-writing-style/SKILL.md`
thedixitjain