asplos-reproducibility
Use when hardening an ASPLOS paper's results for independent repetition — pinning simulator versions and configs, recording kernel/firmware/BIOS state, packaging FPGA bitstreams and RTL, documenting hardware dependencies an evaluator may lack, and writing availability statements that match what the ACM badges will later require.
Profile →npx skills add brycewang-stanford/Awesome-Journal-Skills --skill asplos-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.
# ASPLOS Reproducibility Systems results decay fast: a kernel update, a microcode revision, or a silently changed simulator default can move numbers by more than the paper's claimed margin. Reproducibility work at ASPLOS is therefore **state capture** — recording the full machine, model, and toolchain state behind every figure — done while the experiments run, not reconstructed at camera-ready time. It also front-loads artifact evaluation: the badge criteria (`asplos-artifact-evaluation`) are exactly a demand that this state capture exists and works. ## The state ledger Maintain one ledger row per experimental platform, committed alongside results: | Layer | Capture | Why it moves numbers | |---|---|---| | Silicon | CPU model + stepping, memory config/topology, device (e.g. CXL expander) firmware | Steppings differ in errata and prefetch behavior | | Firmware/BIOS | Microcode revision; SMT, turbo, prefetcher, C-state, NUMA settings | Any one knob can swamp a 10% effect | | OS | Kernel version + full config, relevant sysctls, mitigations state | Speculation mitigations alone shift syscall-heavy results | | Toolchain | Compiler + flags, libraries, runtime versions | -O level and allo
- The state ledger
- Scripted capture beats remembered capture
- The hardware-access problem, named honestly
- Claim-preservation, not number-worship
- Timing across the ASPLOS cycle
- One command per figure
- Trace and dataset provenance
- When numbers drift between submission and revision
- Output format
state-capture.sh — commit this file and its output with each result set uname -a; cat /proc/cmdline grep -m1 'model name' /proc/cpuinfo; grep microcode /proc/cpuinfo | sort -u cat /sys/devices/system/cpu/vulnerabilities/* 2>/dev/null | sort -u cat /sys/devices/system/cpu/smt/control 2>/dev/null numactl --hardware 2>/dev/null | head -5 cc --version | head -1 git -C "$SIM_DIR" rev-parse HEAD 2>/dev/null # simulator commit sha256sum "$BITSTREAM" 2>/dev/null # FPGA bitstream identity
What does the asplos-reproducibility skill do?
Use when hardening an ASPLOS paper's results for independent repetition — pinning simulator versions and configs, recording kernel/firmware/BIOS state, packaging FPGA bitstreams and RTL, documenting hardware dependencies an evaluator may lack, and writing availability statements that match what the ACM badges will later require.
How do I install it?
Run `npx skills add brycewang-stanford/Awesome-Journal-Skills --skill asplos-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.