/atc-author-response
Use when writing the ATC (ACM SIGOPS Annual Technical Conference, formerly USENIX ATC) rebuttal and the shepherd's description-of-changes — the short round-two response that corrects factual misreadings and supplies requested measurements, and the point-by-point revision record
$ npx -y skills add brycewang-stanford/Awesome-Journal-Skills --skill atc-author-response --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/atc-author-response
Context preview
The summary Claude sees to decide when to auto-load this skill.
Use when writing the ATC (ACM SIGOPS Annual Technical Conference, formerly USENIX ATC) rebuttal and the shepherd's description-of-changes — the short round-two response that corrects factual misreadings and supplies requested measurements, and the point-by-point revision record
SKILL.md
atc-author-response.SKILL.mdname: atc-author-response
description: Use when writing the ATC (ACM SIGOPS Annual Technical Conference, formerly USENIX ATC) rebuttal and the shepherd's description-of-changes — the short round-two response that corrects factual misreadings and supplies requested measurements, and the point-by-point revision record a conditional-acceptance shepherd checks before final acceptance.
ATC Author Response
ATC gives you two distinct writing moments after review, and they have different jobs. The **rebuttal** (a short, roughly one-page window during round two) is for correcting misreadings and supplying a measurement a reviewer said was missing. The **description of changes** (after a **conditional accept**, for the **shepherd**) is a point-by-point record proving every required revision was made. Confusing the two — arguing in the shepherd round, or over-promising in the rebuttal — is the classic failure.
The rebuttal (round two, ~1 page)
Its job is narrow and its space is tiny, so triage ruthlessly:
- **Correct factual misreadings** first — a reviewer who misread the testbed, the baseline, or the
claim can be moved by a precise correction with a pointer to the section/figure.
- **Supply the one number that matters** — if a reviewer said "no tail latency" or "no matched-cost
comparison," and you have or can add it, state the result concisely. Systems reviewers move on evidence, not on rhetoric.
- **Concede cleanly** what you cannot fix this cycle — a crisp "correct; here is the honest bound"
buys more credibility than defending an overclaim.
- **Do not argue taste** — "the reviewer underrates the contribution" changes nothing; the PC
discussion decides.
Structure it as **reviewer/point → response**, lead with the highest-impact corrections, and never introduce unsupported new claims (which read as scope creep). Keep double-blind: the rebuttal must not reveal identity.
The description of changes (shepherd round)
After a conditional accept, a PC member **shepherds** the paper: final acceptance depends on the required revisions landing. Write the change record as a contract:
- **One row per required change:** reviewer/shepherd request → what you changed → where (section,
figure, table) → the resulting text or result.
- **Make or explicitly decline** every requested change. A **silently skipped** required change is
the fastest way to stall a conditional accept; if you decline, give the reason and the evidence.
- **Point to concrete artifacts of the change** — the new figure, the added experiment, the revised
paragraph — not a promise to do it.
- **Keep the shepherd's scope.** The shepherd enforces the required revisions, not a new round of
wishes; do not reopen settled scope or add unrequested claims that invite fresh review.
Mapping requests to moves
| Reviewer request | Strong response | |---|---| | "Baseline is weak / unmatched" | Add the well-configured baseline at a matched operating point; report the new comparison | | "No tail latency / variance" | Add p99/p999 and multi-run variance; point to the updated figure | | "Unclear how it's built / scales" | Add implementation detail or a scaling experiment; cite the new section | | "Costs not reported" | Quantify the trade beside the gain at matched cost | | "Reproducibility unclear" | Point to the anonymized artifact and the claim-to-experiment map | | A misreading | Correct precisely with a section/figure pointer; do not over-explain |
What moves an outcome vs. what does not
[Moves it] a factual correction; a requested measurement supplied; a clean concession + bound
[Doesn't] arguing the reviewer's taste; re-asserting the abstract; vague "we will consider"
[Backfires] unsupported new claims; scope creep; defensiveness; an anonymity leak
Reverify each cycle
- Whether a formal rebuttal window exists and its length (about one page is the reported norm —
confirm on the call).
- The shepherding requirements and the change-record format for the current edition.
- The camera-ready deadline relative to the shepherd sign-off (see `atc-camera-ready`).
Output format
[Response type] round-two rebuttal / shepherd description-of-changes
[Triage] highest-impact corrections and requested measurements listed first
[Per point] request -> response -> evidence/location; every required change made or declined-with-reason
[Anonymity] no identity leak in the response? yes/no
[Forbidden] unsupported new claims / taste arguments / silently skipped required changes: absent?
Read more
name: atc-author-response description: Use when writing the ATC (ACM SIGOPS Annual Technical Conference, formerly USENIX ATC) rebuttal and the shepherd's description-of-changes — the short round-two response that corrects factual misreadings and supplies requested measurements, and the point-by-point revision record a conditional-acceptance shepherd checks before final acceptance.
ATC Author Response
ATC gives you two distinct writing moments after review, and they have different jobs. The **rebuttal** (a short, roughly one-page window during round two) is for correcting misreadings and supplying a measurement a reviewer said was missing. The **description of changes** (after a **conditional accept**, for the **shepherd**) is a point-by-point record proving every required revision was made. Confusing the two — arguing in the shepherd round, or over-promising in the rebuttal — is the classic failure.
The rebuttal (round two, ~1 page)
Its job is narrow and its space is tiny, so triage ruthlessly:
- **Correct factual misreadings** first — a reviewer who misread the testbed, the baseline, or the
claim can be moved by a precise correction with a pointer to the section/figure.
- **Supply the one number that matters** — if a reviewer said "no tail latency" or "no matched-cost
comparison," and you have or can add it, state the result concisely. Systems reviewers move on evidence, not on rhetoric.
- **Concede cleanly** what you cannot fix this cycle — a crisp "correct; here is the honest bound"
buys more credibility than defending an overclaim.
- **Do not argue taste** — "the reviewer underrates the contribution" changes nothing; the PC
discussion decides.
Structure it as **reviewer/point → response**, lead with the highest-impact corrections, and never introduce unsupported new claims (which read as scope creep). Keep double-blind: the rebuttal must not reveal identity.
The description of changes (shepherd round)
After a conditional accept, a PC member **shepherds** the paper: final acceptance depends on the required revisions landing. Write the change record as a contract:
- **One row per required change:** reviewer/shepherd request → what you changed → where (section,
figure, table) → the resulting text or result.
- **Make or explicitly decline** every requested change. A **silently skipped** required change is
the fastest way to stall a conditional accept; if you decline, give the reason and the evidence.
- **Point to concrete artifacts of the change** — the new figure, the added experiment, the revised
paragraph — not a promise to do it.
- **Keep the shepherd's scope.** The shepherd enforces the required revisions, not a new round of
wishes; do not reopen settled scope or add unrequested claims that invite fresh review.
Mapping requests to moves
| Reviewer request | Strong response | |---|---| | "Baseline is weak / unmatched" | Add the well-configured baseline at a matched operating point; report the new comparison | | "No tail latency / variance" | Add p99/p999 and multi-run variance; point to the updated figure | | "Unclear how it's built / scales" | Add implementation detail or a scaling experiment; cite the new section | | "Costs not reported" | Quantify the trade beside the gain at matched cost | | "Reproducibility unclear" | Point to the anonymized artifact and the claim-to-experiment map | | A misreading | Correct precisely with a section/figure pointer; do not over-explain |
What moves an outcome vs. what does not
[Moves it] a factual correction; a requested measurement supplied; a clean concession + bound [Doesn't] arguing the reviewer's taste; re-asserting the abstract; vague "we will consider" [Backfires] unsupported new claims; scope creep; defensiveness; an anonymity leak
Reverify each cycle
- Whether a formal rebuttal window exists and its length (about one page is the reported norm —
confirm on the call).
- The shepherding requirements and the change-record format for the current edition.
- The camera-ready deadline relative to the shepherd sign-off (see `atc-camera-ready`).
Output format
[Response type] round-two rebuttal / shepherd description-of-changes [Triage] highest-impact corrections and requested measurements listed first [Per point] request -> response -> evidence/location; every required change made or declined-with-reason [Anonymity] no identity leak in the response? yes/no [Forbidden] unsupported new claims / taste arguments / silently skipped required changes: absent?
Stanford REAP × CoPaper.AI · 由斯坦福实证方法论团队精选与维护 访问 copaper.ai 微信:CoPaper.AI 按 11 个主流学科板块覆盖 经管与商科 社会科学 人文学科 数学与物理科学 生命科学 医学与健康 工程与技术 计算机科学与 AI 体育科学 点击任一学科名可跳转到对应说明;每类下的代表子领域在正文总览中完整列出。下方封面墙按 venue 导航,完整分类见覆盖一览。 🧭 布局指南 · 📚 Skill Pack 一览 · ⚡ 如何使用 · 🧪 自动实证
Other skills on awesome-journal-skills.
- /aaai-artifact-evaluation
Use when packaging AAAI code, data, multimedia appendices, technical appendices, reproducibility evidence, and post-acceptance artifact releases without violating double-blind or immutable-supplement rules.
Open skill - /aaai-author-response
Use when drafting an AAAI author response (rebuttal) under the single short character-limited author-feedback window, the no-URL rule, no-new-results guidance, AI-generated-review handling, and the AAAI two-phase review process where Phase-2 papers receive one feedback round
Open skill - /aaai-camera-ready
Use when preparing an accepted AAAI paper for camera-ready source submission to AAAI Press, including proceedings page limits, two-column template compliance, copyright transfer, purchased extra technical pages, deanonymization, registration, oral or poster presentation, and
Open skill - /aaai-experiments
Use when designing or auditing AAAI experiments for the broad-AI program committee, including baselines, ablations, statistical significance, robustness, human evaluation, AI-for-Social-Impact and alignment/safety evidence, compute and cost reporting, and
Open skill - /aaai-related-work
Use when positioning an AAAI paper's novelty against archival work, contemporaneous arXiv or workshop papers, and AAAI/IJCAI/NeurIPS/ICML/ICLR neighbors across the broad AI scope, while staying inside AAAI's dual-submission and AI-as-source policy constraints and writing a
Open skill - /aaai-reproducibility
Use when strengthening an AAAI paper's reproducibility checklist (placed after references), experimental traceability, seed and hyperparameter reporting, compute and cost disclosure, dataset access and licensing, code/data ZIP readiness, and the claim-to-evidence map that
Open skill

