Skip to content
Content
Skill

/asplos-author-response

Use when drafting an ASPLOS author response inside the short fixed window — triaging reviews into factual errors versus questions versus disagreements, budgeting for the ~800 words reviewers are expected to read, arguing only from evidence already in the submission, and

From plugin
awesome-journal-skills
965200 skills
Install
$ npx -y skills add brycewang-stanford/Awesome-Journal-Skills --skill asplos-author-response --agent claude-code

How 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/asplos-author-response

Context preview

The summary Claude sees to decide when to auto-load this skill.

Use when drafting an ASPLOS author response inside the short fixed window — triaging reviews into factual errors versus questions versus disagreements, budgeting for the ~800 words reviewers are expected to read, arguing only from evidence already in the submission, and

SKILL.md

asplos-author-response.SKILL.md
name: asplos-author-response
description: Use when drafting an ASPLOS author response inside the short fixed window — triaging reviews into factual errors versus questions versus disagreements, budgeting for the ~800 words reviewers are expected to read, arguing only from evidence already in the submission, and positioning the paper for the Accept / Major Revision / Reject decision.

ASPLOS Author Response

The 2027 CFP defines the rebuttal's job narrowly: **(1) correct factual errors in the reviews, and (2) answer the questions reviewers posed.** There is no hard length cap, but reviewers are **not expected to read past 800 words** (verified 2026-07-08). Both facts should shape every drafting decision below. The 2027 windows are fixed and short — July 6-9, 2026 for the April cycle (open on this pack's check date) and December 1-4, 2026 for the September cycle.

Hour one: triage before prose

Sort every review remark into exactly one bucket:

| Bucket | Definition | Response posture | |---|---|---| | **Factual error** | The review misstates what the paper says, measures, or assumes | Correct it, with a section/figure/table pointer — highest priority, CFP-sanctioned | | **Direct question** | The reviewer asked for a clarification | Answer in ≤ 3 sentences, citing where the paper already contains the material | | **Evidence dispute** | The reviewer doubts a result or baseline | Point to the existing run/ablation that addresses it; concede if none exists | | **Judgment call** | "Not novel enough", "fit is marginal" | One calm paragraph max, or zero — rebuttals rarely move taste | | **Revision seed** | A fixable gap you agree with | Acknowledge + state the concrete fix; this is you negotiating the Major Revision terms |

The last bucket is ASPLOS-specific leverage: because the decision set includes **Major Revision**, a response that shows requested work is *scoped and feasible in six weeks* gives the committee a reason to choose revision over rejection.

The 800-word budget

Assume only the first 800 words are read; structure so truncation is harmless:

Words   1- 80   Global note: 1-2 sentences of thanks + the single most
                important correction, stated flatly with a pointer.
Words  80-560   Numbered items, worst objection first. Format per item:
                [R2-Q1] Claim/question -> answer -> evidence pointer (§, Fig, Tab).
Words 560-800   Revision seeds: "If given the opportunity, we will X, Y, Z" —
                each one concrete, bounded, and honest about what exists today.
Overflow        Optional detail annex, clearly marked; assume unread.

Write pointers, not paraphrases: "§6.4's ablation isolates the hint register (row 3 of Table 5)" outlasts three sentences of re-argument.

Rules of evidence

  • Argue **only from the submitted PDF and its appendices**. New numbers produced

during a four-day window read as unreviewable and can poison trust in the reviewed ones.

  • If a reviewer misread because the paper was unclear, say both halves: the correct

reading, and that the text will be clarified — the misreading is data about your writing.

  • Never restate a weakness in stronger words than the reviewer used; answer the

version they wrote.

  • Preserve anonymity: no identifying links, no "as we showed in our earlier paper"

in the first person.

Anticipating each decision from the response

  • **Toward Accept:** every factual error corrected with pointers; questions

answered; no new promises needed.

  • **Toward Major Revision:** disputes conceded where real, each paired with a

bounded fix — you are drafting the revision contract's terms in your own language before the committee writes them in theirs.

  • **Away from Reject:** the response's tone matters most on the margin; a defensive

or evasive rebuttal confirms a skeptical reviewer's prior. Flat, specific, checkable sentences are the house style.

Team protocol for a 3-4 day window

1. Day 0 (reviews arrive): full-team read; triage table filled; owner per item. 2. Day 1: draft answers with pointers verified against the submitted PDF — not the current working draft, which has diverged. 3. Day 2: cut to budget; adversarial read by the author who wrote least of it. 4. Final day: submit early; HotCRP forms have closing times, and AoE arithmetic under deadline stress is how windows get missed.

Sentence patterns, graded

Systems reviewers reward flatness and pointers; they punish advocacy verbs.

  • Works: *"R2 states the baseline ran untuned; §6.1 documents the three

tunables we set and their values, matching the vendor guide."* — correction, pointer, checkable.

  • Works: *"Yes — the design targets sub-VM granularity; §3.4's interface

section defines the virtualization behavior R1 asks about."* — direct answer first, location second.

  • Fails: *"We respectfully disagree with the reviewer's assessment of

novelty."* — spends words restating the objection, adds no evidence.

  • Fails: *"As is well known in the community..."* — condescension detector;

if it were well known, the reviewer would know it.

  • Fails: *"We will completely rewrite Section 5."* — unbounded promise; the

Major Revision channel rewards bounded, verifiable commitments only.

When reviews contradict each other

Reviewer A wants the simulator sweep expanded; reviewer B calls simulation the paper's weakness. Do not privately pick a side: name the tension in one neutral sentence and resolve it with the claim-instrument logic ("the sweep tests generality; the silicon runs carry the headline claim — §6.2 vs §6.5"), so the committee discussion inherits your framing instead of improvising one. A response that surfaces and resolves a contradiction reads as authors who understand their own evidence architecture.

Arming your champion

A response is read most attentively by the reviewer already inclined to argue for the paper. Give that reviewer portable ammunition: one-sentence answers they can

Read more
Ships withawesome-journal-skills

Stanford REAP × CoPaper.AI · 由斯坦福实证方法论团队精选与维护 访问 copaper.ai 微信:CoPaper.AI 按 11 个主流学科板块覆盖 经管与商科 社会科学 人文学科 数学与物理科学 生命科学 医学与健康 工程与技术 计算机科学与 AI 体育科学 点击任一学科名可跳转到对应说明;每类下的代表子领域在正文总览中完整列出。下方封面墙按 venue 导航,完整分类见覆盖一览。 🧭 布局指南 · 📚 Skill Pack 一览 · ⚡ 如何使用 · 🧪 自动实证

Get the whole plugin
Stats
965
Stars
121
Forks
Active
Maintenance
Stata
Language
MIT
License
13h ago
Last commit
2mo ago
Created

Repo: brycewang-stanford/Awesome-Journal-Skills

Other skills on awesome-journal-skills.