Agent Skills
› brycewang-stanford/Awesome-Journal-Skills
› atc-reproducibility
atc-reproducibility
GitHub指导为ATC系统论文构建可复现性故事，包括固定软硬件环境、提供一键复现实验脚本、封装匿名可运行工件及准备评价包，以争取Available/Functional/Reproduced徽章。
Trigger Scenarios
撰写ATC或USENIX ATC系统类论文
需要配置实验环境的可复现性
准备论文投稿的匿名化评估包
Install
npx skills add brycewang-stanford/Awesome-Journal-Skills --skill atc-reproducibility -g -y
SKILL.md
Frontmatter
{
"name": "atc-reproducibility",
"description": "Use when building the reproducibility story for an ATC (ACM SIGOPS Annual Technical Conference, formerly USENIX ATC) systems paper — pinning testbed and software environments, providing a turnkey path from the artifact to the headline numbers, and preparing an anonymized-but-runnable review package ahead of the Available\/Functional\/Reproduced badges."
}
ATC Reproducibility
Build the reproducibility story alongside the system, not at the deadline. ATC has an active
artifact culture inherited from USENIX: reviewers expect a runnable, anonymized artifact at review
time, and after acceptance an Artifact Evaluation Committee awards Available / Functional /
Reproduced badges (see atc-artifact-evaluation). The through-line is that a systems result other
people can re-run is worth more than one they must take on faith — and systems provenance cannot be
reconstructed after the fact.
Pin what you cannot reconstruct
Record these at collection time; none can be recovered at the deadline:
[Hardware] CPU/NIC/SSD models, core/memory counts, firmware/BIOS where it matters
[OS/kernel] kernel version, distro, relevant sysctl/tuning, hugepages/NUMA settings
[Toolchain] compiler, library, and runtime versions; build flags
[Workload] trace source + extraction date, generator version + seeds, request mix
[Method] warm-up window, measurement duration, run count, aggregation method
[Code] commit SHAs for your system and every baseline; patches applied
A turnkey path to the headline numbers
The single most valuable artifact property is that an evaluator can regenerate your paper's main figures and tables:
- Ship a claim-to-experiment map: paper claim → script → expected figure/table → expected runtime.
- Provide a one-command entry point per headline result (
./run_fig3.sh) that does setup, run, and plot. - Give a small-scale mode for evaluators who lack your hardware (fewer nodes, a trace sample), and state clearly which results are full-scale-only and why.
- Log expected outputs and tolerances so an evaluator knows what "reproduced" looks like given measurement noise.
Pinned, portable environments
- Prefer a container (Dockerfile) or a pinned environment (lockfile,
requirements, Nix) over "install these 30 packages by hand." - Where the result depends on kernel features or hardware (RDMA, SPDK, io_uring, specific NICs), say so explicitly and document the required host, since a container cannot abstract the hardware away.
- Include traces/datasets (or documented, durable access), not just the query that produced them.
Anonymized-but-runnable review package
At submission the artifact must be runnable yet double-blind:
- No owner strings, cluster hostnames, lab or product names, or identity-revealing URLs in code, configs, logs, or commit metadata.
- Mirror any linked repository behind an anonymizing service; scrub
.git/from archives. - The system's own name can de-anonymize you — use a neutral placeholder if the real name is identifying, and reconcile it in the camera-ready.
- Verify the package runs from a clean checkout on a fresh machine — "works on the author's laptop" is the most common Functional failure.
Honest reproducibility posture
- If a result cannot be shared (proprietary trace, confidential deployment), say so and why, and provide the closest reproducible substitute — silence reads as a weakness.
- Distinguish reproducible (same artifact, same numbers) from replicable (independent reimplementation) and claim only what you support.
- For experience/deployed-systems papers, provide what you can — configs, anonymized traces, analysis scripts — even when the production system itself cannot ship.
Output format
[Provenance] hardware/OS/toolchain/workload/method/code pinned at collection time? gaps?
[Turnkey] claim-to-experiment map + one-command runs + small-scale mode present? yes/no
[Environment] container or pinned lockfile? hardware dependencies documented?
[Anonymity] artifact runnable AND double-blind (no names/hosts/owner strings)? yes/no
[Clean-machine] runs from a fresh checkout on a clean host? yes/no
[Badge readiness] on track for Available / Functional / Reproduced? blockers?
Version History
- 9f86f09 Current 2026-07-19 14:20
