nsdi-author-response
GitHub针对NSDI会议，指导作者在无正式反驳阶段时，通过在论文中预埋回应或在一次性修订中严格对照要求列表进行修改。涵盖异议预判、修订执行规则及变更备忘录与高亮差异的撰写，旨在高效满足审稿人要求并最大化录用概率。
Trigger Scenarios
Install
npx skills add brycewang-stanford/Awesome-Journal-Skills --skill nsdi-author-response -g -y
SKILL.md
Frontmatter
{
"name": "nsdi-author-response",
"description": "Use when answering NSDI reviewers through the channel the venue actually provides — executing a one-shot revision against the required-issues list, writing the change memo and highlighted diff for the same reviewers, and pre-empting objections inside the submission when no response phase exists."
}
NSDI Author Response
At NSDI the author's voice reaches reviewers at two moments only: inside the original submission, and — if granted — inside a one-shot revision packet read by the same people who wrote the demands. There is no rendered rebuttal phase in the '27 CFP (absence 待核实; verify each cycle). This skill covers both moments; the second is the venue's signature mechanism and the reason this skill is not a rebuttal-writing guide.
Moment one: the response you embed in advance
Without a mid-review channel, anticipated objections must be answered in the PDF:
- Run the objection drill: each coauthor writes the three most likely reviewer
complaints; any complaint appearing twice gets a paragraph in the paper —
typically a "why not X?" design-alternatives note or a limits paragraph
(
nsdi-writing-style). - Pre-empt the baseline attack by documenting baseline tuning in-body
(
nsdi-experiments). - Pre-empt the scope attack with an explicit sentence locating the contribution in
the networking stack or distributed design (
nsdi-topic-selection).
Moment two: the one-shot revision, treated as a contract
The decision letter's required-issues list is an offer with exact terms: fix these, same reviewers check, one attempt. Respond like a contractor, not a debater.
Triage the issues within days of notification:
| Issue type | Typical cost | Response posture |
|---|---|---|
| New experiment / baseline | machine-weeks + testbed access | reserve infrastructure immediately (nsdi-workflow) |
| Analysis or clarity | days | do fully; these are free credibility |
| Claim recalibration | hours, plus ego | almost always concede — narrow the claim to the evidence |
| Genuinely infeasible demand | — | contact the program co-chairs early; silence then surprise is the worst path |
Execution rules:
- Address every listed issue, visibly. Coverage is binary at NSDI: revisions that fail to address the required issues are rejected with no further revision option. Partial credit does not exist.
- Do not renovate beyond the list. The same reviewers approved everything they did not flag; gratuitous rewrites reopen settled sections and can introduce new objections that the one-shot format gives you no chance to answer.
- If an experiment's result contradicts the reviewer's expectation, report it straight. The issue said "evaluate under churn," not "show churn is fine." An honest unfavorable result plus a scoped claim is a fulfilled requirement; a massaged favorable one is a rejection when the reviewer probes.
The packet: memo + highlighted diff
Both components are mandatory auxiliary material (nsdi-supplementary). Their shared
purpose: let a reviewer verify their own issue in under a minute.
Change memo skeleton (one block per required issue, in the letter's order):
R-1 Compare against <deployed system>.
DONE — §6.2 now includes tuned <system> (config: App. C).
Result: our gains drop from 3.4x to 2.6x at p99.9; text and
abstract recalibrated. [diff pages 8-9, 1]
R-2 Clarify lease-expiry semantics.
DONE — new §4.3 (state machine, Fig. 5); two corner cases we
had not specified are now explicit. [diff pages 5-6]
Also changed (minimal): fixed two typos flagged in reviews; updated
citation [31] to its published version. No other content changes.
The "Also changed" section builds the trust the format depends on — it certifies the diff is complete. Generate the highlighted version mechanically (latexdiff or equivalent) from the true submitted baseline, not from a reconstructed one.
Tone: the readers already invested in this paper — a one-shot revision means they voted to see it again. Write as a colleague closing out a punch list: no re-argument of the original decision, no flattery, no hedging about what was and wasn't done.
Timeline for a typical revision window
A spring '27 one-shot revision (notified July 23, 2026) targeting the fall gate (September 17, 2026) has roughly eight weeks:
- Week 1: issue ledger built; infeasibility flags raised with co-chairs if any; testbed time reserved.
- Weeks 2-5: demanded experiments run with full provenance
(
nsdi-reproducibility); text changes drafted in parallel. - Week 6: memo and diff assembled from the running drafts; internal reviewer plays the original R2 against the packet.
- Week 7: freeze; verify the resubmission enters the correct HotCRP site with
the packet attached (
nsdi-submission). - Week 8: buffer — the revision that arrives calm beats the one that arrives complete-but-chaotic at 11:58 pm.
A fall-issued revision aiming at the next edition's spring gate has more calendar but the same structure; do not let the longer runway defer the testbed reservation.
When the letter says plain reject
There is no response channel and no appeal-by-email; the ban clock runs
(nsdi-review-process). The productive move is extraction: convert each review
point into either a fix, a re-route signal, or a documented disagreement to handle
in the next version's pre-emption layer. The reviews were written by this
community; the next PC will resemble them.
Output format
[Channel] pre-emption (drafting) / one-shot revision (letter in hand)
[Issue ledger] R-# -> action -> cost -> owner -> status
[Feasibility] any issue needing co-chair contact? deadline realistic?
[Packet status] memo issue-complete? diff from true baseline? extras declared?
[Risk] unfavorable-result handling; renovation creep check
[Ship date] resubmission gate targeted, freeze date set
Version History
- 9f86f09 Current 2026-07-19 17:07
