Agent Skills
› brycewang-stanford/Awesome-Journal-Skills
› sigmetrics-author-response
sigmetrics-author-response
GitHub用于ACM SIGMETRICS论文审稿回复。重点指导如何撰写一次性修改回应信，逐项关闭审查员要求的修改清单，确保在双盲复审中通过。涵盖事实纠错、证据补充及截稿日期选择策略。
Trigger Scenarios
收到SIGMETRICS One-Shot Revision决定
需要回复ACM SIGMETRICS审稿意见
Install
npx skills add brycewang-stanford/Awesome-Journal-Skills --skill sigmetrics-author-response -g -y
SKILL.md
Frontmatter
{
"name": "sigmetrics-author-response",
"description": "Use when responding to ACM SIGMETRICS reviews, covering any initial rebuttal and — distinctively — the one-shot revision response letter that must map every item on the reviewers' required-changes list to a concrete change in the revised POMACS paper, resubmitted to a subsequent rolling deadline and re-reviewed once by the original reviewers under double-anonymity."
}
SIGMETRICS Author Response
Use this after SIGMETRICS reviews are released. The defining SIGMETRICS response is the one-shot revision letter: if you receive a One-Shot Revision decision, you get exactly one chance to resubmit a revised paper (to one of the next two rolling deadlines) accompanied by a letter that closes the reviewers' explicit list of required changes. Any initial-round rebuttal is secondary; the revision letter is where the paper is won.
Triage
- Answer what affects the decision: model rigor, proof correctness, assumption validity, the soundness and fairness of empirical/simulation evidence, novelty, and reproducibility.
- Use evidence that already exists or that the revision will concretely add — a completed proof case, a new simulation, a validated assumption — never a vague promise.
- Correct factual misreadings first; a reviewer who misread a lemma or a plot is often persuadable.
- Preserve double-anonymity in any letter that circulates before decision (the Operational Systems Track excepted).
The one-shot revision response letter (the distinctive SIGMETRICS move)
A One-Shot Revision is single-shot: there is no second revision, so the letter must demonstrate that every item on the required-changes list is resolved. It is a change ledger:
[R1.1] Required change (quoted briefly): "prove the bound holds for the heavy-tailed case"
-> Action: DONE | added Thm. 1 case (b) and its proof in §3.2 (App. B for the full derivation)
-> Where: §3.2, Appendix B; simulator run in artifact/sim/heavy_tail.ipynb validates it
[R2.1] Required change: "validate the M/G/1 assumption against a real workload"
-> Action: DONE | added §5.1 fitting the service-time distribution to the trace; QQ-plot Fig. 6
[R2.2] Required change: "compare against the size-aware optimal, not only the default"
-> Action: DONE | added the SRPT-style baseline, tuned with an equal budget (Table 2)
[R3.1] Required change: "discuss estimation error in fetch size"
-> Action: DONE | §6 quantifies degradation under estimation error and bounds it
The rule that turns a One-Shot Revision into an acceptance: close the whole list. Because the revision is re-reviewed once against that list, an item neither done nor explicitly and convincingly justified as infeasible is what the single shot punishes.
Choosing the resubmission deadline
- You may target one of the two subsequent deadlines — pick the later one if closing the list needs a real proof or a new measurement campaign; do not rush a single-shot revision into the nearer deadline and leave an item half-done.
- Keep the paper under the SIGMETRICS process while revising: submitting the same work elsewhere before withdrawing is a simultaneous-submission violation.
Reviewer pushback patterns
| Pushback | What it signals | SIGMETRICS-ready response |
|---|---|---|
| "The proof omits a case / an assumption is unstated" | Rigor/correctness doubt | Add the case or state the assumption explicitly; give the full derivation in an appendix |
| "The model assumption is unrealistic" | Construct validity of the model | Fit the assumption to a real workload/trace; quantify the gap and bound its effect |
| "The baseline is not the right/optimal one" | Fairness of the comparison | Add the strongest baseline (e.g. size-aware optimal), tuned with an equal, documented budget |
| "Simulation and analysis are not shown to agree" | Validation gap | Overlay the analytic curve on simulated measurements with confidence intervals |
| "Not reproducible" | Open-science gap | Ship the seeded simulator, trace-processing scripts, and analysis notebooks |
Anonymity in the letter (easy to slip)
- Refer to your own prior work in the third person, as in the paper.
- Describe artifact changes without linking to an identity-revealing repository; use the anonymized location.
- Do not thank a named collaborator or funder inside a letter that circulates before decision.
Calibration
- Respond to the criterion the reviewer actually raised, not the one you would rather defend.
- The revision, not the letter, carries the argument — the letter maps the list; the paper proves the point.
- Length/format norms for the letter vary by cycle; confirm the current instructions before sending.
Output format
[Turn] initial rebuttal / one-shot revision response letter
[Resubmission deadline] which subsequent rolling deadline, and why
[Priority issue] <reviewer required change>
[Decision dimension] rigor / proof / assumption validity / evidence / novelty / reproducibility
[Change ledger] <required change -> DONE/JUSTIFIED-INFEASIBLE + where in paper/appendix/artifact>
[List-closure check] every required change resolved? yes/no
[Anonymity check] <no identity leak in the letter: passed/issues>
Version History
- 9f86f09 Current 2026-07-19 17:36
