aaai-artifact-evaluati…
Use when packaging AAAI code, data, multimedia appendices, technical appendices, reproducibility evidence, and post-acceptance artifact releases without…
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.
/atc-author-responseContext 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
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 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.
Its job is narrow and its space is tiny, so triage ruthlessly:
claim can be moved by a precise correction with a pointer to the section/figure.
comparison," and you have or can add it, state the result concisely. Systems reviewers move on evidence, not on rhetoric.
buys more credibility than defending an overclaim.
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.
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:
figure, table) → the resulting text or result.
the fastest way to stall a conditional accept; if you decline, give the reason and the evidence.
paragraph — not a promise to do it.
wishes; do not reopen settled scope or add unrequested claims that invite fresh review.
| 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 |
[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
confirm on the call).
[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 一览 · ⚡ 如何使用 · 🧪 自动实证
Use when packaging AAAI code, data, multimedia appendices, technical appendices, reproducibility evidence, and post-acceptance artifact releases without…
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,…
Use when preparing an accepted AAAI paper for camera-ready source submission to AAAI Press, including proceedings page limits, two-column template compliance,…
Use when designing or auditing AAAI experiments for the broad-AI program committee, including baselines, ablations, statistical significance, robustness, human…
Use when positioning an AAAI paper's novelty against archival work, contemporaneous arXiv or workshop papers, and AAAI/IJCAI/NeurIPS/ICML/ICLR neighbors across…
Use when strengthening an AAAI paper's reproducibility checklist (placed after references), experimental traceability, seed and hyperparameter reporting,…