Agent Skills
› brycewang-stanford/Awesome-Journal-Skills
› cav-author-response
cav-author-response
GitHub针对CAV会议二阶段审稿后，指导通过初筛论文撰写回复信。重点回应证明正确性、基准公平性及新颖性质疑，强调使用可验证证据而非承诺，并严格保持双盲匿名。
Trigger Scenarios
收到CAV会议第二阶段审稿意见
需要为通过初审的论文撰写 rebuttal
处理关于定理证明或实验设置的质疑
Install
npx skills add brycewang-stanford/Awesome-Journal-Skills --skill cav-author-response -g -y
SKILL.md
Frontmatter
{
"name": "cav-author-response",
"description": "Use when drafting a CAV (Computer Aided Verification) author response (rebuttal) for a paper that has passed the two-stage review's first filter, covering how to answer soundness\/proof objections, benchmark-fairness challenges, and novelty-delta doubts with verifiable evidence while preserving double-anonymity for Regular and Application papers."
}
CAV Author Response
Use this after CAV stage-2 reviews are released. At CAV the rebuttal exists only for papers that passed the stage-1 filter — the two-stage process means a rejected paper never reaches this turn. So the rebuttal is a focused instrument: answer what the two additional reviewers, and the two from stage 1, need in order to advocate for the paper in the PC discussion. For Regular and Application papers, the response must respect double-anonymity — do not reveal authors, the tool's real name, or identity-revealing repositories.
Triage
- Answer what affects the decision: soundness of the theorem/proof, fairness and reproducibility of the benchmarks, novelty/delta against prior verification work, scope, and clarity.
- Use evidence that already exists in the submission or that you can state precisely — a proof step, a number already in a table, a benchmark-configuration clarification. Do not promise unrun experiments as if they were results.
- Correct factual misreadings first; a reviewer who misread a theorem's assumption or a benchmark subset is often persuadable.
- Keep every word anonymous for anonymized categories. (Tool and Industrial papers are not double-blind, so this constraint relaxes — but still avoid gratuitous self-promotion.)
The verification rebuttal, point by point
Treat the response as a claim ledger: for each reviewer concern, either resolve it with concrete evidence or explain precisely why the concern does not apply.
[R1.1] "The soundness proof assumes X, which fails for unbounded inputs."
-> Response: X is not assumed; Lemma 2 holds for unbounded inputs (the bound is only on
the encoding width, §3.2). Pointer: §3.2, Lemma 2.
[R2.1] "The baseline solver was not the latest version / not tuned."
-> Response: baseline is vA.B (latest release at submission); we used its default portfolio
as recommended in its README; per-instance data in the artifact confirms parity of limits.
[R2.2] "Novelty over <prior technique> is unclear."
-> Response: prior technique shares lemmas only propositionally; ours admits theory lemmas
under a re-derivation check (the soundness contribution), see §3.3 and Table 2.
The rule that turns a stage-2 paper into an acceptance: answer the axis the reviewer raised, with something they can verify — a section pointer, a proof step, or a benchmark fact — not a promise.
Reviewer pushback patterns
| Pushback | What it signals | CAV-ready response |
|---|---|---|
| "The soundness argument is incomplete" | Correctness doubt | Point to the exact lemma/assumption, or concede and scope the claim |
| "The baseline is outdated or untuned" | Evaluation-fairness doubt | Name the version and configuration; show equal resource limits from the artifact |
| "Only easy/self-selected benchmarks" | External-validity limit | Point to the standard set/revision used; state the class not covered as a limit |
| "Delta over prior work X is thin" | Novelty doubt | Name the precise technical difference (what X cannot do that you do) |
| "The tool did not build / is missing" | Reproducibility gap | Clarify the build path; note the artifact plan (AEC is post-acceptance) |
| "Claim generality is over-stated" | Scope objection | Narrow the claim in the response and promise the camera-ready scoping edit |
Anonymity in the response (anonymized categories)
- Refer to your own prior work in the third person, as in the paper.
- Describe tool/benchmark changes without naming the real tool or linking an identity-revealing repository; use the anonymized location.
- Do not thank a named collaborator or funder inside the response.
Calibration
- Respond to the criterion the reviewer actually raised, not the one you would rather defend.
- Length and format norms for the response vary by cycle; confirm the current instructions and the word/character limit before sending.
- The PC discussion decides; write the response as evidence for an advocate, and let the paper — not the rebuttal — carry the argument.
Output format
[Turn] stage-2 rebuttal (only for papers past the stage-1 filter)
[Priority issue] <reviewer concern>
[Decision dimension] soundness/proof / benchmark-fairness / novelty / scope / clarity / tool
[Claim ledger] <concern -> resolved with (proof step / number / pointer) or scoped>
[Anonymity check] <no identity leak for Regular/Application: passed/issues>
Version History
- 9f86f09 Current 2026-07-19 14:38
