sosp-reproducibility
Use when hardening the reproducibility of a SOSP paper's results before submission — pinning the OS-level environment, recording hardware and topology, making every figure regenerable from logged runs, separating measurement noise from effect size, and preparing the ground for post-acceptance artifact evaluation.
Profile →npx skills add brycewang-stanford/Awesome-Journal-Skills --skill sosp-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.
# SOSP Reproducibility Use this while experiments are being designed and run — months before the SOSP deadline, not during artifact evaluation. At SOSP the artifact process happens after acceptance (see `sosp-artifact-evaluation`), which means reproducibility discipline has a different job pre-submission: it protects **you**. Reviewers probe numbers during a three-month review cycle and a response phase in which new experiments are forbidden; the only defensible paper is one whose every number can be traced to a logged, re-runnable measurement of a pinned system. ## The OS-research twist: your system changes the platform An operating-systems artifact often *is* the environment — a modified kernel, a new scheduler, an interposed I/O path. That collapses the usual app/platform separation and creates specific hazards: - A rebased kernel patch series can silently change baseline behavior; record the exact base commit and the full patch stack for every run, including baseline runs. - Firmware, microcode, and mitigations (for example, speculative-execution mitigations) can dominate syscall-heavy microbenchmarks; log them and hold them constant across system and baseline. - Frequency scal
- The OS-research twist: your system changes the platform
- Capture the environment mechanically
- One command per figure
- Variance is a first-class result
- Traces and workloads you cannot publish
- Output format
capture-env.sh — run on every experiment node, archive with the run's results uname -a; cat /etc/os-release | head -2 cat /proc/cmdline # mitigations, isolcpus, hugepages lscpu | grep -E 'Model name|Socket|NUMA|MHz' free -h | head -2; lsblk -d -o NAME,MODEL,ROTA,SIZE ip -br link; ethtool eth0 2>/dev/null | grep -E 'Speed|Duplex' git -C "$REPO" rev-parse HEAD; git -C "$REPO" status --porcelain
What does the sosp-reproducibility skill do?
Use when hardening the reproducibility of a SOSP paper's results before submission — pinning the OS-level environment, recording hardware and topology, making every figure regenerable from logged runs, separating measurement noise from effect size, and preparing the ground for post-acceptance artifact evaluation.
How do I install it?
Run `npx skills add brycewang-stanford/Awesome-Journal-Skills --skill sosp-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.