sosp-author-response
GitHub用于在SOSP会议前撰写作者回复，严格限定于纠正事实错误和回答审稿人直接提问。禁止引入新实验或承诺后续工作，建议控制在500字以内，旨在澄清误解以辅助程序委员会讨论。
Trigger Scenarios
Install
npx skills add brycewang-stanford/Awesome-Journal-Skills --skill sosp-author-response -g -y
SKILL.md
Frontmatter
{
"name": "sosp-author-response",
"description": "Use when drafting a SOSP author response during the pre-PC-meeting rebuttal window, keeping it within the venue's norms — correcting factual errors, answering direct reviewer questions, staying near the 500-word guidance, and never introducing new experiments, new data, or promises of future work."
}
SOSP Author Response
Use this when SOSP reviews land and the response window opens. SOSP's response phase has an unusually narrow charter, stated in the CFP (verified 2026-07-08 for the 2026 cycle): responses exist to correct factual errors in the reviews and to answer questions reviewers explicitly posed. They must not add new experiments or data, describe work done since submission, or promise follow-up work. Submitting a response is optional, and while no hard cap is stated, authors are strongly encouraged to stay under 500 words.
What the response can and cannot do
The response is read by a program committee that will discuss the paper live at a PC meeting. Its job is to remove false obstacles before that discussion, not to renegotiate the paper.
| Move | Allowed at SOSP? | Why |
|---|---|---|
| "Review B states we hold the lock across I/O; §4.2 shows it is released before the write" | Yes | Factual correction, cites the submitted text |
| Answering "how does this behave when the log fills?" with what the submission already supports | Yes | Direct reviewer question |
| "We have since run the benchmark on 128 nodes and..." | No | New data after the deadline |
| "We will add a comparison against X in the final version" | No | Promised work |
| Re-arguing novelty against a reviewer's taste judgment | Technically allowed, usually wasted words | Not a factual error |
| Pointing to the supplementary document for detail the reviewer missed | Yes, sparingly | It was part of the submission |
Hour-zero triage
Read all reviews once without drafting anything, then classify every negative point:
- Factual error — the review misstates what the paper says or does. Highest priority; these are the response's reason to exist.
- Missed content — the answer is in the paper but the reviewer did not find it. Respond with a section/figure pointer and one sentence of restatement.
- Direct question — answer it crisply from the submitted material.
- Judgment call — "not novel enough," "evaluation could be broader." Spend at most one sentence, or zero; the PC meeting will weigh these, and defensive prose does not move systems reviewers.
If categories 1-3 are empty, seriously consider not responding: an optional response that only pushes back on judgments can read worse than silence.
Budgeting 500 words
- Open with two sentences maximum of thanks and framing; no summary of the paper.
- Order points by expected impact on the PC discussion, not by reviewer order.
- Quote the review's exact claim in a few words before rebutting, so a PC member skimming during the meeting can follow without the full review open.
- Cite the submission by section, figure, or table number every time — the submitted PDF is the only evidence you are allowed to use.
Response skeleton (target < 500 words total)
We thank the reviewers. We correct three factual points and answer two questions.
[Factual] Rev A: "the design requires a second network round trip."
It does not: the token is piggybacked on the existing ack (§3.3, Fig. 4).
[Factual] Rev C: "no failure experiments."
§5.4 and Table 6 report crash-restart and partition runs on the same workloads.
[Question] Rev B asked how recovery time scales with log size.
Recovery replays only the tail past the last checkpoint; §4.5 gives the bound
and Fig. 9 measures it at three log sizes.
[Clarification] Rev A read the consistency guarantee as per-object; it is
per-session (§2, invariant I2). The distinction affects the Rev A example: ...
Tone calibration for a single-track PC
Every accepted SOSP paper is discussed in front of the whole committee, so your response's audience is wider than the three or four people who reviewed it. Write so a non-reviewer PC member encountering the paper for the first time at the meeting sees authors who are precise, unrattled, and honest about limits. Concede real weaknesses in one clean sentence ("The evaluation does not include workload X; the submitted results cover Y and Z") rather than burying them — a concession you volunteer is a footnote at the meeting, one you dodge becomes the meeting's topic.
Common failure modes
- Spending the word budget proportionally to review length instead of review influence.
- Correcting five trivialities and leaving the one score-driving misreading to last.
- Smuggling in a new number "for context" — chairs notice, and it taints the compliant parts of the response.
- Addressing reviewers by name-like inference ("as the senior reviewer notes..."); reviews are anonymous in both directions.
- Writing 900 words because no hard limit exists. The 500-word guidance is a signal about attention at the PC meeting, not a formality.
Output format
[Respond at all?] yes / no (categories 1-3 empty)
[Point map] <review point -> factual error / missed content / question / judgment>
[Word budget] <allocation across points, total target>
[Concession] <the one weakness to own explicitly>
[Compliance check] no new data / no promises / submission-only citations
Version History
- 9f86f09 Current 2026-07-19 17:38
