isca-reproducibility
Use when making an ISCA paper's results regenerable — pinning simulator versions and local patches, archiving per-figure configuration manifests, recording workload provenance and sampling seeds, quantifying run-to-run variation on real hardware, and keeping the environment resurrectable through the February window.
Profile →npx skills add brycewang-stanford/Awesome-Journal-Skills --skill isca-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.
# ISCA Reproducibility In architecture, "reproducible" means someone else — or you, three months later, mid-rebuttal — can regenerate every reported number from recorded state. Because most ISCA numbers come out of simulators, reproducibility here is largely *configuration archaeology*: the result is a function of tool commit, local patches, model parameters, workload build, region selection, and warm-up policy, and losing any one of those breaks the chain. The venue reinforces this culture with post-acceptance artifact evaluation under ACM badging (`isca-artifact-evaluation`); this skill covers the discipline that must exist *before* any AE form is filled. ## The result chain, and what to pin at each link | Link | What drifts silently | Pin it by | |---|---|---| | Simulator | Version-to-version behavior changes; forgotten local edits | Exact commit hash + `git diff` of local patches archived with results | | Machine model | Config files edited during exploration | One immutable config per experiment family; configs referenced by hash | | Workloads | Compiler/flags/inputs change binaries | Archive binaries or lockfile the build; record input sets by checksum | | Regions & warm-up |
- The result chain, and what to pin at each link
- One manifest per published number
- Nondeterminism gets measured, not ignored
- Paper-side reporting
- Resurrectability: the February requirement
- Habits that make all of this cheap
- Pre-submission reproducibility gate
- Where each practice pays off later
results/ f07-headline/ manifest.ini # instrument, model, measurement, workloads regen.sh # rebuild -> run -> aggregate -> plot, no hands raw/ # simulator stats as emitted (never edited) derived/f07.csv # scripted aggregation output f07.pdf # exactly the file included in the paper The submission-freeze ritual: git tag isca27-submitted && \ sha256sum results/*/f*.pdf paper/fig/*.pdf | sort | uniq -c -w64 | \
What does the isca-reproducibility skill do?
Use when making an ISCA paper's results regenerable — pinning simulator versions and local patches, archiving per-figure configuration manifests, recording workload provenance and sampling seeds, quantifying run-to-run variation on real hardware, and keeping the environment resurrectable through the February window.
How do I install it?
Run `npx skills add brycewang-stanford/Awesome-Journal-Skills --skill isca-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 984 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.