| name | dac-author-response |
| description | Use when handling reviewer feedback for an ACM/IEEE Design Automation Conference (DAC) Research Manuscript — writing a concise, evidence-first rebuttal IF the cycle runs an author-response period (verify; DAC has historically not), and otherwise converting DAC reviews into a targeted response-to-reviewers when rerouting a rejected paper to ICCAD, DATE, ASP-DAC, or a journal. |
DAC Author Response
Handle reviews with DAC's process in mind. The single most important fact: DAC's Research-Manuscript
review has historically been TPC-driven without an author rebuttal period, and whether the
current cycle runs one is 待核实 (resources/official-source-map.md). So this skill covers two
situations, and the second is the common one.
Situation A — the cycle runs a response period (verify first)
If — and only if — the live DAC cycle offers an author response, treat it as a short, factual
correction channel, not a debate. EDA reviewers reject mostly on baseline fairness, benchmark
credibility, and scalability; a response moves a borderline paper when it supplies a number or
corrects a factual misreading, and moves nothing when it argues taste.
Priorities for a tight EDA rebuttal (assume a strict word budget):
- Fix factual errors first — a reviewer who thinks you did not compare against tool X when
Table 2 does; point to the table.
- Answer the baseline objection with evidence — if a reviewer names a stronger baseline, report
the number if you have it, or commit precisely to what you will add and why it will not change the
conclusion.
- Address scalability with data — cite the largest-benchmark runtime already in the paper, or
give the missing figure.
- Concede cheaply, defend what matters — accept small corrections plainly; spend your words on
the one or two objections that actually decide the paper.
Do not promise experiments you cannot run before camera-ready, and do not introduce
author-revealing information — the response is still within double-blind.
[Reviewer 2] "No comparison to [SOTA router]."
Response: We compare against [SOTA router] in Table 2 (columns 4-6); on the full ISPD set we reduce
overflow by X% at equal wirelength. We will make this comparison more prominent.
Situation B — no rebuttal, then a reject (the common case)
With no response channel, the review packet arrives with the decision. The productive use of DAC
reviews is then to repair the paper and reroute it well. DAC, ICCAD, DATE, and ASP-DAC share
reviewer pools and criteria, so a DAC reviewer's objection is very likely to resurface at the next
venue — answer it in the paper, not in a letter no one will read.
Turn the reviews into a fix list:
| DAC review objection | Fix before resubmitting elsewhere |
|---|
| Weak/untuned baseline | Add the strongest SOTA tool, tuned to equal effort, before ICCAD/DATE |
| Private benchmarks only | Re-run on ISPD/EPFL/ISCAS/ITC/TAU so the QoR is comparable |
| Scalability doubted | Add million-cell-scale results and runtime |
| Gain not isolated | Add the ablation the reviewer implicitly asked for |
| Incremental novelty | Extend the mechanism, or reframe honestly for a journal (TCAD/TODAES) |
If you reroute to a journal (TCAD/TODAES), a response letter does exist
Journals do run revise-and-resubmit with a point-by-point response. There, write the letter DAC
never asked for: map every reviewer point to a tracked change, quote the review, state the change,
and give the new number. That is where the discipline of ../dac-experiments pays off — a rejected
DAC paper with a strong QoR story often becomes a clean journal accept.
What never works
- Arguing novelty by assertion — "our approach is fundamentally different" without a QoR delta
persuades no EDA reviewer.
- Blaming the benchmarks — if the standard suite does not flatter you, that is a signal, not an
excuse.
- Waiting for a rebuttal that may not come — build the paper so it needs no rebuttal; the
baseline and benchmark choices must be unimpeachable at submission.
Output format
[Response mode] rebuttal (cycle confirmed) / no-rebuttal reroute / journal response letter
[Decision driver] baseline | benchmark | scalability | novelty | clarity
[Point map] each review point -> factual correction | evidence | conceded | reframe
[If rerouting] target venue (ICCAD/DATE/ASP-DAC/TCAD) + the top fix to make first
[Anonymity] response (if any) free of author-revealing info? yes/no
