MobiSys Author Response
Use this after MobiSys round-2 reviews are released. Reopen the current rebuttal instructions
and length limit before drafting, because scope and mechanics are cycle-specific. The MobiSys
rebuttal is narrow by design: it is not a revision and not a place to reargue the paper.
Scope discipline
- The rebuttal is for correcting factual errors in the reviews and answering specific
questions reviewers posed. Stay inside that scope.
- New experiments are admissible only if they directly address reviewer feedback;
alternatively, you may promise results expected by the camera-ready deadline — but only
ones you can actually deliver.
- Keep the reply double-blind: no institution, authorship, private repository, or
identity-revealing device/account detail.
- Use existing submitted evidence first: figures, appendix tables, device provenance, and the
artifact — point to them precisely rather than restating them.
Triage
- Answer concerns that affect the decision: is the system real, is the on-device evidence
sufficient, is the energy/latency claim defensible, is the contribution a system.
- Correct factual misreadings first (a reviewer who thinks you tested one device when you
tested four), then address requests for a missing baseline, an energy boundary, or a
break-condition experiment.
- One decision-critical point per reviewer beats an exhaustive reply; the AC reads for whether
the central objection was actually resolved.
Drafting pattern
- State the decision-critical correction or concession first.
- Point to exact submitted evidence (figure, table, appendix, artifact).
- Explain the systems consequence — what it means for the device claim.
- Promise a camera-ready fix only if it adds no unsupported claim and you can deliver it.
Systems-reviewer pushback patterns
| Pushback |
What it signals |
MobiSys-ready fix |
| "Evaluated on one device" |
Generalization doubt |
Point to the multi-device table, or promise the added device honestly |
| "Energy numbers are unconvincing" |
Undefined instrument/boundary |
Name the power monitor, sampling rate, and envelope already in App. A |
| "Only a 30-second benchmark" |
Throttling hidden |
Reference the sustained-load run and thermal trace, or promise one |
| "This is a better model, not a system" |
Fit doubt |
Re-anchor the contribution as the runtime/scheduling mechanism, with the ablation that isolates it |
Response micro-example
Reviewer objection: the latency win might vanish once the device throttles. Reply skeleton:
- Concede the concern is the right one to raise for sustained load.
- Point to the 20-minute run in Fig. 1 and the thermal trace in App. A, already submitted.
- Note the win holds to steady state on all four devices, with the numbers regenerable from
the artifact.
- Offer one camera-ready sentence making the steady-state result explicit in the body.
Output format
[Priority issue] <reviewer concern>
[Decision dimension] contribution / on-device evidence / energy-latency rigor / clarity
[Draft response] <MobiSys-ready anonymous text within scope>
[Evidence anchor] <figure/table/appendix/artifact item>
[Out-of-scope content removed] <reargument, identity leaks, undeliverable promises>
Source: brycewang-stanford/Awesome-Journal-Skills → MobiSys-Skills/skills/mobisys-author-response/SKILL.md
1---2name: mobisys-author-response3description: Use when drafting a MobiSys rebuttal after round-2 reviews — working within the scope limit (correct factual errors, answer specific reviewer questions), adding only directly-responsive new results, promising camera-ready work honestly, staying double-blind, and giving the area chair a clean rationale for a mobile-systems accept decision.4---567# MobiSys Author Response89Use this after MobiSys round-2 reviews are released. Reopen the current rebuttal instructions10and length limit before drafting, because scope and mechanics are cycle-specific. The MobiSys11rebuttal is **narrow by design**: it is not a revision and not a place to reargue the paper.1213## Scope discipline1415- The rebuttal is for **correcting factual errors** in the reviews and **answering specific16 questions** reviewers posed. Stay inside that scope.17- New experiments are admissible **only if they directly address reviewer feedback**;18 alternatively, you may **promise** results expected by the camera-ready deadline — but only19 ones you can actually deliver.20- Keep the reply **double-blind**: no institution, authorship, private repository, or21 identity-revealing device/account detail.22- Use existing submitted evidence first: figures, appendix tables, device provenance, and the23 artifact — point to them precisely rather than restating them.2425## Triage2627- Answer concerns that affect the **decision**: is the system real, is the on-device evidence28 sufficient, is the energy/latency claim defensible, is the contribution a system.29- Correct factual misreadings first (a reviewer who thinks you tested one device when you30 tested four), then address requests for a missing baseline, an energy boundary, or a31 break-condition experiment.32- One decision-critical point per reviewer beats an exhaustive reply; the AC reads for whether33 the central objection was actually resolved.3435## Drafting pattern36371. State the decision-critical correction or concession first.382. Point to exact submitted evidence (figure, table, appendix, artifact).393. Explain the systems consequence — what it means for the device claim.404. Promise a camera-ready fix only if it adds no unsupported claim and you can deliver it.4142## Systems-reviewer pushback patterns4344| Pushback | What it signals | MobiSys-ready fix |45|---|---|---|46| "Evaluated on one device" | Generalization doubt | Point to the multi-device table, or promise the added device honestly |47| "Energy numbers are unconvincing" | Undefined instrument/boundary | Name the power monitor, sampling rate, and envelope already in App. A |48| "Only a 30-second benchmark" | Throttling hidden | Reference the sustained-load run and thermal trace, or promise one |49| "This is a better model, not a system" | Fit doubt | Re-anchor the contribution as the runtime/scheduling mechanism, with the ablation that isolates it |5051## Response micro-example5253Reviewer objection: the latency win might vanish once the device throttles. Reply skeleton:54551. Concede the concern is the right one to raise for sustained load.562. Point to the 20-minute run in Fig. 1 and the thermal trace in App. A, already submitted.573. Note the win holds to steady state on all four devices, with the numbers regenerable from58 the artifact.594. Offer one camera-ready sentence making the steady-state result explicit in the body.6061## Output format6263```text64[Priority issue] <reviewer concern>65[Decision dimension] contribution / on-device evidence / energy-latency rigor / clarity66[Draft response] <MobiSys-ready anonymous text within scope>67[Evidence anchor] <figure/table/appendix/artifact item>68[Out-of-scope content removed] <reargument, identity leaks, undeliverable promises>69```7071---7273**Source:** [`brycewang-stanford/Awesome-Journal-Skills`](https://github.com/brycewang-stanford/Awesome-Journal-Skills) → `MobiSys-Skills/skills/mobisys-author-response/SKILL.md`
thedixitjain