usenixsec-author-response
GitHub指导作者应对USENIX Security会议审稿，涵盖中期回复与Shepherd阶段。提供审查分类策略、合规性处理（如伦理问题）及写作规范，强调引用证据、保持匿名并遵守版本机制变化。
触发场景
安装
npx skills add brycewang-stanford/Awesome-Journal-Skills --skill usenixsec-author-response -g -y
SKILL.md
Frontmatter
{
"name": "usenixsec-author-response",
"description": "Use when reviews arrive from a USENIX Security Symposium cycle and the authors must respond — writing the rebuttal that survives online PC discussion, handling required ethics-content revisions flagged mid-review, and working with a shepherd after an \"Accepted on Shepherd Approval\" decision."
}
USENIX Security Author Response
USENIX Security gives authors two distinct speaking moments, and they obey different rules: the mid-review response to reviewers, and the post-decision exchange with a shepherd. This skill covers both. Mechanics shift per cycle — the '25 model was documented in detail on the reviewing-model page, the '26 model partially, and the '27 mechanics are 待核实 — so confirm the current instructions in HotCRP before drafting.
Where the response sits in the pipeline
In the '25 model (the last fully documented one): two reviews in round one; papers survive to round two if at least one reviewer sees a path to acceptance after online discussion; round two adds two more reviews; then authors respond; reviewers discuss again and decide. Two consequences follow:
- By the time you respond, four reviewers have read the paper but the committee has not settled. The response's real audience is the discussion that follows it.
- Papers cut at the early-reject notification never get a response window at all.
There is no appeal lane inside the cycle; the recovery move is a revised
resubmission (see
usenixsec-review-processfor the restriction rules).
One more '25-documented pattern worth planning for: submissions with inadequate ethics discussions were flagged during review, and authors were required to supply revised ethics content in the response phase. Treat an ethics question in a review as a compliance demand, not an opinion to debate.
Sorting the reviews before writing
| Objection type | What it usually means at this venue | Response move |
|---|---|---|
| Threat model unrealistic | Reviewer rejects the attacker capabilities | Defend with deployment evidence, or narrow the claim explicitly |
| Ethics gap / disclosure question | Compliance flag, possibly chair-visible | Answer completely; state disclosure timeline and vendor contact status |
| Evaluation missing an adaptive attacker | Defense papers' most common kill | Present the adaptive experiment if it exists; commit precisely if it fits shepherding scope |
| Overlap with concurrent work | Cycle collision, common with two cycles/year | Date the overlap, differentiate mechanism and evidence |
| "Measurement may be artifact of vantage point" | Methodology doubt | Show cross-vantage or cross-time consistency numbers |
Answer the compliance-shaped items first and fully; a brilliant technical rebuttal does not offset an unanswered disclosure question.
Drafting rules that fit this venue
- Number every point and quote the review fragment being answered; the discussion phase skims, and unanchored prose gets skipped.
- Give evidence that already exists (a table row, an appendix reference, a number) priority over promises. Since '26 the largest change a paper can absorb after decision is a two-week shepherding pass — never promise revisions bigger than that window can hold.
- Keep anonymity discipline: no identifying links, no "in our lab" phrasing.
- If a reviewer misread, demonstrate the misreading with a page/section pointer and move on without scoring the point.
# Response skeleton (per review point)
[R2.3] "the scanner may overload targets"
Facts: Section 5.2 caps probe rate at 1 req/s/host; opt-out honored within 24h
(Appendix: Ethical Considerations, para 2).
Change offered: none needed — pointer only.
[R1.4] "no adaptive attacker"
Facts: new experiment, gradient-aware evader, detection drops 94%→81% (table below).
Change offered: add as Sec 6.4 (~0.5 page); fits shepherding scope.
After the decision: shepherd mode
"Accepted on Shepherd Approval" (the '26 outcome replacing major revisions) means the committee wants the paper but conditions publication on named changes — clarifications, limitation discussions, toned-down claims — that are unlikely to change enthusiasm. Working rules:
- Convert the decision letter into a change matrix (request → edit → location) and send it to the shepherd before editing, so scope is agreed once.
- Deliver inside the two-week window; the shepherd's sign-off is the acceptance.
- Do not smuggle in new results the committee never reviewed; flag anything beyond the requested list explicitly and let the shepherd rule on it.
- Track every edit against the camera-ready deadline for your cycle — shepherding
and final-paper preparation overlap (see
usenixsec-camera-ready).
Reverify each cycle
- Whether the current cycle includes an author response phase at all, its length, and its format (HotCRP field vs PDF) — '27 values 待核实.
- The shepherding window length and whether "Accepted on Shepherd Approval" remains the intermediate outcome.
- Any word/character limit on responses.
Output format
[Phase] mid-review response / shepherd exchange
[Compliance items] ethics or disclosure questions + answers drafted: yes/no
[Point map] review point → evidence → offered change (within shepherding scope?)
[Risk] points conceded or narrowed, and the wording
[Next deadline] response or shepherd deadline, camera-ready implications
版本历史
- 9f86f09 当前 2026-07-19 17:52
