dac-review-process
Use when reasoning about how an ACM/IEEE Design Automation Conference (DAC) Research Manuscript is evaluated, covering double-blind TPC review, the novelty-plus-QoR decision criteria, program-committee discussion, the accept/reject (no major-revision) outcome, the ~20-25% selectivity, and how DAC's industry-facing, single-shot process differs from the architecture venues' rebuttal-and-revision cycles.
Profile →npx skills add brycewang-stanford/Awesome-Journal-Skills --skill dac-review-process --agent claude-code
Same command for any agent — swap --agent for codex, cursor, copilot.
Weekly change comes from our own snapshots, not the repository page — it measures attention, not adoption.
# DAC Review Process Model the pipeline before interpreting any single review. DAC's Research-Manuscript review is **double-blind, Technical-Program-Committee-driven, and single-shot**: papers are reviewed against novelty and measured design-quality impact, discussed by the committee, and get a binary **accept/reject** — there is no journal-style Major Revision round. Anchor to the DAC 2026 cycle facts in `resources/official-source-map.md`. ## Process model - Submission and review run on **Softconf/START** with **double-blind** anonymity: reviewers do not see author identities, and the manuscript must be scrubbed of identifying content. - Each paper is read by multiple **TPC** members drawn from the relevant subcommittee (physical design, logic synthesis, verification/test, ML-for-EDA, security, embedded, etc.). Reviewers weigh **novelty over prior art, technical soundness, the strength and fairness of the QoR evidence, relevance/impact to design automation, and clarity**. - The committee **discusses** borderline papers to reach the final verdict; a strong advocate who can answer the objections carries a paper through discussion. - Decisions are essentially **accept or reject** (a
- Process model
- Reading a decision against the criteria
- Novelty-plus-QoR: the DAC bar
- How DAC differs from its siblings
- Who reads you
- Where author leverage actually exists
- Misreadings to avoid
- Output format
What does the dac-review-process skill do?
Use when reasoning about how an ACM/IEEE Design Automation Conference (DAC) Research Manuscript is evaluated, covering double-blind TPC review, the novelty-plus-QoR decision criteria, program-committee discussion, the accept/reject (no major-revision) outcome, the ~20-25% selectivity, and how DAC's industry-facing, single-shot process differs from the architecture venues' rebuttal-and-revision cycles.
How do I install it?
Run `npx skills add brycewang-stanford/Awesome-Journal-Skills --skill dac-review-process --agent claude-code` — it drops the skill into your project so the agent can pick it up. Swap the --agent value for codex, cursor or copilot if you use one of those.
Where does this skill come from?
From brycewang-stanford/Awesome-Journal-Skills, a repository with 909 stars. We read it straight from the repository tree rather than a submitted listing, so what you see here is what is actually published.
Is a popular skill a good skill?
Not necessarily. Stars measure attention, not adoption — a repository can trend for a week and be abandoned. That is why we show the weekly change from our own snapshots next to the total, instead of a single flattering number.