dac-reproducibility
Use when building the reproducibility story for an ACM/IEEE Design Automation Conference (DAC) Research Manuscript, covering pinned EDA benchmark suites and versions (ISPD, EPFL, ISCAS/ITC, TAU, CircuitNet), open-source flow provenance (OpenROAD, ABC, Yosys), PDK/library and tool-version disclosure, seed/variance reporting for stochastic and ML flows, and the anonymized-then-public repository path — absent a formal DAC artifact-badging track.
Profile →npx skills add brycewang-stanford/Awesome-Journal-Skills --skill dac-reproducibility --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 Reproducibility Build the reproducibility story into the evaluation, not onto it. DAC does **not** run a formal, badge-issuing artifact-evaluation track for research manuscripts (**待核实** per cycle), so reproducibility at DAC is not a review checkbox — it is what makes your QoR numbers *credible* to a skeptical EDA reviewer and *usable* by the community that cites you. The currency is **pinned benchmarks, disclosed tool versions, and re-runnable flows**. ## The EDA reproducibility floor - **Pin the benchmark suite and version.** Name the exact suite (ISPD 2005/2015 contests, the EPFL combinational suite, ISCAS'85/'89, ITC'99, a TAU contest set, CircuitNet/OpenABC-D) and the specific release. "Standard benchmarks" without a version is not reproducible. - **Disclose the flow and tool versions.** State the EDA tools and versions used — open (OpenROAD, ABC, Yosys, KLayout) or commercial — because QoR depends heavily on the flow. If a commercial tool or PDK is under NDA, say which class of tool it is and give what you can. - **Name the PDK / technology / library.** QoR numbers are meaningless without the technology node and standard-cell library context (e.g., an open Nangate/ASAP7
- The EDA reproducibility floor
- Seeds, variance, and stochastic flows
- The anonymized-then-public repository path
- Claim-to-reproduction mapping
- What DAC-specific reproducibility is not
- Output format
What does the dac-reproducibility skill do?
Use when building the reproducibility story for an ACM/IEEE Design Automation Conference (DAC) Research Manuscript, covering pinned EDA benchmark suites and versions (ISPD, EPFL, ISCAS/ITC, TAU, CircuitNet), open-source flow provenance (OpenROAD, ABC, Yosys), PDK/library and tool-version disclosure, seed/variance reporting for stochastic and ML flows, and the anonymized-then-public repository path — absent a formal DAC artifact-badging track.
How do I install it?
Run `npx skills add brycewang-stanford/Awesome-Journal-Skills --skill dac-reproducibility --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.