Agent Skills
› brycewang-stanford/Awesome-Journal-Skills
› siggraph-author-response
siggraph-author-response
GitHub用于撰写SIGGRAPH/Asia论文 rebuttal（1000字纯文本）及条件录用后的修订计划。指导如何纠正事实错误、回答具体问题，避免引入新结果，并针对关键评审意见进行高效策略性回复。
Trigger Scenarios
撰写SIGGRAPH论文rebuttal
处理条件录用后的第二阶段修订
Install
npx skills add brycewang-stanford/Awesome-Journal-Skills --skill siggraph-author-response -g -y
SKILL.md
Frontmatter
{
"name": "siggraph-author-response",
"description": "Use when writing the SIGGRAPH \/ SIGGRAPH Asia Technical Papers rebuttal, the single 1000-word text-only author response uploaded during the rebuttal window to correct factual errors and answer specific reviewer questions before the Technical Papers Committee meeting, and when planning the change list for a conditionally accepted paper's second-stage revision."
}
SIGGRAPH Author Response
SIGGRAPH gives you exactly one written turn before the decision — the rebuttal — and, if the
paper is conditionally accepted, a second-stage revision handled through the camera-ready. These
are different instruments; do not treat the rebuttal like a journal response letter. Facts below
were read from the SIGGRAPH 2026 reviewer-instructions/ethics page on 2026-07-09
(resources/official-source-map.md); reconfirm the length and window on the live call.
The rebuttal: a hard 1000-word, text-only turn
- Length: up to 1000 words of text only — no images, no video, no URLs to external pages. Everything you say must be self-contained in prose. (SIGGRAPH 2026 window: 5-12 March 2026; upload before 22:00 UTC/GMT on the close date.)
- Timing: you see the complete set of reviews when the window opens; the rebuttal is read by the referees and factored into the Technical Papers Committee discussion that produces the decision.
- Purpose (narrow): correct factual errors in the reviews and answer specific questions. It is not a channel for new results, revised text, or a redesigned evaluation that does not directly answer a reviewer's question. Promising a new experiment rarely moves a score; correcting a reviewer's factual misreading can.
Triage the reviews before writing a word
- Separate factual errors from judgments. "The method cannot handle X" when your Section 4 shows X is a factual error you can flip; "the contribution is incremental" is a judgment you can only reframe. Spend words where they change a number.
- Find the pivotal reviewer. With a small committee and a single score scale (Strong Reject ... Strong Accept), the borderline reviewer whose vote decides the paper is your audience. Answer the objection that is actually holding the score down, not the easiest one.
- Cluster shared concerns. If two reviewers doubt the same comparison, answer it once, well, and cross-reference — you cannot afford to repeat yourself inside 1000 words.
- Concede cheaply, defend precisely. Acknowledge real limitations in one clause and move on; spend the saved words on the one or two objections that decide acceptance.
What actually persuades a graphics committee
- Point to evidence already in the submission. "Fig. 7 (row 3) and the supplemental video at 0:45 already show the failure case the reviewer asks for" beats "we will add this." You cannot attach new media, but you can direct referees to what you submitted.
- Quantify a correction. If a reviewer misread a timing, state the correct number and where it appears. Numbers close factual gaps that adjectives cannot.
- Name the comparison honestly. If a reviewer wants a baseline you did not run, say whether it is applicable, what it would likely show, and why your existing comparisons already bound the claim — do not bluff a result.
- Protect the results video. Many graphics rejections turn on artifacts a reviewer saw in motion. If the criticism is about a visual artifact, address the specific shot and timestamp; if it is a genuine limitation, say so and scope the claim.
Draft structure (fits 1000 words)
[Opening 1-2 sentences] Thank reviewers; state the 2-3 decisions your response will address.
[R-common] The shared concern (e.g., missing comparison / validation), answered once with evidence.
[R1 / R2 / R3 specific] Only the factual errors and specific questions that affect the score.
[Limitations] One honest paragraph: what you concede and how you will scope claims in revision.
[Close] One sentence on the concrete change the camera-ready will make if conditionally accepted.
The second stage: conditional acceptance is a revision, not a formality
If the committee conditionally accepts the paper, a Technical Papers Committee member verifies the final version in a second reviewing process — required changes must actually be made. Treat the conditions as a checklist:
- Map each required change to a specific edit, figure, or added result and track it.
- Deliver every promised revision; the second-stage reviewer can withhold final acceptance if conditions are unmet.
- Keep the supplemental video and code in sync with the revised claims — a fixed artifact must be re-rendered, not just described.
See siggraph-camera-ready for the mechanics of the conditionally-accepted final version.
Anti-patterns
- Spending words re-explaining the method instead of answering the objection.
- Promising experiments you cannot run, or implying media you cannot attach.
- Arguing with a judgment ("this is novel") rather than supplying the missing fact.
- Ignoring the pivotal reviewer to score easy points off a lenient one.
- Exceeding 1000 words or embedding a link/figure — mechanically stripped or penalized.
Output format
[Rebuttal plan] pivotal reviewer + the 2-3 decisions to address
[Factual corrections] <review claim -> correct fact -> where it already appears>
[Concessions] <limitation conceded -> how claims will be scoped>
[Word budget] running count against 1000, text-only confirmed
[If conditionally accepted] <required change -> planned edit -> owner>
Version History
- 9f86f09 Current 2026-07-19 17:35
