/atc-artifact-evaluation
Use when packaging an ATC (ACM SIGOPS Annual Technical Conference, formerly USENIX ATC) artifact for the USENIX-lineage evaluation scheme — earning the Artifacts Available, Artifacts Functional, and Results Reproduced badges from the Artifact Evaluation Committee on its separate
$ npx -y skills add brycewang-stanford/Awesome-Journal-Skills --skill atc-artifact-evaluation --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/atc-artifact-evaluation
Context preview
The summary Claude sees to decide when to auto-load this skill.
Use when packaging an ATC (ACM SIGOPS Annual Technical Conference, formerly USENIX ATC) artifact for the USENIX-lineage evaluation scheme — earning the Artifacts Available, Artifacts Functional, and Results Reproduced badges from the Artifact Evaluation Committee on its separate
SKILL.md
atc-artifact-evaluation.SKILL.mdname: atc-artifact-evaluation
description: Use when packaging an ATC (ACM SIGOPS Annual Technical Conference, formerly USENIX ATC) artifact for the USENIX-lineage evaluation scheme — earning the Artifacts Available, Artifacts Functional, and Results Reproduced badges from the Artifact Evaluation Committee on its separate post-acceptance deadline, with evaluator-proof documentation and a turnkey path to the paper's numbers.
ATC Artifact Evaluation
Use this for the artifact track. ATC follows the shared **USENIX/SIGOPS** artifact-evaluation scheme: an **Artifact Evaluation Committee (AEC)** runs a **separate, post-acceptance** process through HotCRP and awards up to three badges — **Artifacts Available**, **Artifacts Functional**, and **Results Reproduced**. Two things to internalize: badges are earned by evaluators **actually using** your package, and the review artifact (anonymized, for the paper's reviewers) is not the same deliverable as the badge artifact (de-anonymized, permanently archived). ATC's artifact culture is strong and high-participation — for USENIX ATC '25, most evaluated artifacts earned Functional and a large majority earned Reproduced.
The three badges (verify the current set and names)
| Badge | What it certifies | What earns it | |---|---|---| | Artifacts Available | The artifact is permanently, publicly retrievable | Deposit in a DOI-issuing archive (Zenodo, figshare, Software Heritage) | | Artifacts Functional | It is documented, complete, and exercisable — it runs and does what the paper says | Clean-machine install, a demo, scripts + data to run the experiments | | Results Reproduced | An evaluator reproduced the paper's main results | A turnkey path from the artifact to the headline figures/tables |
Available is low-cost, high-value (archive the package). Functional and Reproduced require the evaluator's own run to succeed, so the failure mode is always "did not run on their machine," never "the idea was weak."
What AEC evaluators open first
| Claim type | First thing inspected | Common failure caught | |---|---|---| | A built system / mechanism | The README and one install/run command | Undocumented deps; only-works-on-authors'-hardware | | A performance result | The scripts that turn a run into the paper's figures | Numbers in the PDF no script reproduces | | A result needing specific hardware (RDMA/NVMe/NIC) | The documented host requirements + a small-scale mode | Requires unavailable hardware; no fallback | | A trace-driven study | The traces + the processing scripts | Query shipped, data missing; provenance unpinned |
Assume the evaluator has a bounded time budget on a clean machine and may **lack your exact hardware**. Design the first ten minutes to succeed and provide a reduced-scale path.
Packaging plan
[Container] a Dockerfile or pinned environment; document any host/hardware the container cannot abstract
[README] one-screen orientation: what it is, install, run the demo, reproduce each claim, expected runtime/outputs
[Mapping] an explicit table: paper claim -> script -> expected figure/table -> tolerance
[Scale] a full-scale path AND a small-scale mode for evaluators without the hardware
[Data] the traces/datasets themselves (or durable documented access), not just the query
[Provenance] kernel/OS versions, hardware models, commit SHAs, workload seeds, run counts
[License] an OSI-approved license so the artifact can be shared and reused
[Archive] deposit in a DOI-issuing repository for the Available badge
Anonymized review artifact vs. badge artifact
- **At submission (review):** anonymized for the paper's double-blind reviewers — no owner strings,
cluster hostnames, lab/product names, or identity-revealing links, and no live repo that discloses authors (see `atc-reproducibility`).
- **After acceptance (badge):** replace anonymized placeholders with the public, licensed,
DOI-issuing archive; this is the version the AEC badges and the camera-ready cites.
Worked vignette: a storage-cache policy + measurement
A paper contributes a flash-cache admission policy and a testbed evaluation. To target Functional and Reproduced: ship a container with the modified server pre-built; a `run_demo.sh` that exercises the policy on a bundled trace sample in a minute; a `reproduce/` directory whose scripts regenerate each figure from logged runs; a claim-to-script mapping with tolerances in the README; the production-derived trace sample (with pinned provenance) plus documentation of the full trace's access; a documented note that the full-scale p99 result needs the 12-node testbed, with a single-node small-scale mode; and an MIT/Apache license. State honestly which results are full-scale-only.
Calibration
- The AEC deadline is **after acceptance** and **independent** of the camera-ready — do not conflate
them (plan both in `atc-workflow`).
- Badge names, the exact set offered, and whether evaluation is single- or double-anonymous can vary
by cycle and moved in the SIGOPS transition — confirm on the current call for artifacts.
Output format
[Target badges] Available / Functional / Reproduced
[Artifact role] anonymized review artifact / public badge artifact
[Contents] <system/data/scripts/provenance/license/archive>
[Ten-minute test] install + demo succeed on a clean machine? yes/no
[Reproduce] claim -> script -> expected figure present? small-scale mode for missing hardware? yes/no
[Fixes before upload] <ordered list>
Read more
name: atc-artifact-evaluation description: Use when packaging an ATC (ACM SIGOPS Annual Technical Conference, formerly USENIX ATC) artifact for the USENIX-lineage evaluation scheme — earning the Artifacts Available, Artifacts Functional, and Results Reproduced badges from the Artifact Evaluation Committee on its separate post-acceptance deadline, with evaluator-proof documentation and a turnkey path to the paper's numbers.
ATC Artifact Evaluation
Use this for the artifact track. ATC follows the shared **USENIX/SIGOPS** artifact-evaluation scheme: an **Artifact Evaluation Committee (AEC)** runs a **separate, post-acceptance** process through HotCRP and awards up to three badges — **Artifacts Available**, **Artifacts Functional**, and **Results Reproduced**. Two things to internalize: badges are earned by evaluators **actually using** your package, and the review artifact (anonymized, for the paper's reviewers) is not the same deliverable as the badge artifact (de-anonymized, permanently archived). ATC's artifact culture is strong and high-participation — for USENIX ATC '25, most evaluated artifacts earned Functional and a large majority earned Reproduced.
The three badges (verify the current set and names)
| Badge | What it certifies | What earns it | |---|---|---| | Artifacts Available | The artifact is permanently, publicly retrievable | Deposit in a DOI-issuing archive (Zenodo, figshare, Software Heritage) | | Artifacts Functional | It is documented, complete, and exercisable — it runs and does what the paper says | Clean-machine install, a demo, scripts + data to run the experiments | | Results Reproduced | An evaluator reproduced the paper's main results | A turnkey path from the artifact to the headline figures/tables |
Available is low-cost, high-value (archive the package). Functional and Reproduced require the evaluator's own run to succeed, so the failure mode is always "did not run on their machine," never "the idea was weak."
What AEC evaluators open first
| Claim type | First thing inspected | Common failure caught | |---|---|---| | A built system / mechanism | The README and one install/run command | Undocumented deps; only-works-on-authors'-hardware | | A performance result | The scripts that turn a run into the paper's figures | Numbers in the PDF no script reproduces | | A result needing specific hardware (RDMA/NVMe/NIC) | The documented host requirements + a small-scale mode | Requires unavailable hardware; no fallback | | A trace-driven study | The traces + the processing scripts | Query shipped, data missing; provenance unpinned |
Assume the evaluator has a bounded time budget on a clean machine and may **lack your exact hardware**. Design the first ten minutes to succeed and provide a reduced-scale path.
Packaging plan
[Container] a Dockerfile or pinned environment; document any host/hardware the container cannot abstract [README] one-screen orientation: what it is, install, run the demo, reproduce each claim, expected runtime/outputs [Mapping] an explicit table: paper claim -> script -> expected figure/table -> tolerance [Scale] a full-scale path AND a small-scale mode for evaluators without the hardware [Data] the traces/datasets themselves (or durable documented access), not just the query [Provenance] kernel/OS versions, hardware models, commit SHAs, workload seeds, run counts [License] an OSI-approved license so the artifact can be shared and reused [Archive] deposit in a DOI-issuing repository for the Available badge
Anonymized review artifact vs. badge artifact
- **At submission (review):** anonymized for the paper's double-blind reviewers — no owner strings,
cluster hostnames, lab/product names, or identity-revealing links, and no live repo that discloses authors (see `atc-reproducibility`).
- **After acceptance (badge):** replace anonymized placeholders with the public, licensed,
DOI-issuing archive; this is the version the AEC badges and the camera-ready cites.
Worked vignette: a storage-cache policy + measurement
A paper contributes a flash-cache admission policy and a testbed evaluation. To target Functional and Reproduced: ship a container with the modified server pre-built; a `run_demo.sh` that exercises the policy on a bundled trace sample in a minute; a `reproduce/` directory whose scripts regenerate each figure from logged runs; a claim-to-script mapping with tolerances in the README; the production-derived trace sample (with pinned provenance) plus documentation of the full trace's access; a documented note that the full-scale p99 result needs the 12-node testbed, with a single-node small-scale mode; and an MIT/Apache license. State honestly which results are full-scale-only.
Calibration
- The AEC deadline is **after acceptance** and **independent** of the camera-ready — do not conflate
them (plan both in `atc-workflow`).
- Badge names, the exact set offered, and whether evaluation is single- or double-anonymous can vary
by cycle and moved in the SIGOPS transition — confirm on the current call for artifacts.
Output format
[Target badges] Available / Functional / Reproduced [Artifact role] anonymized review artifact / public badge artifact [Contents] <system/data/scripts/provenance/license/archive> [Ten-minute test] install + demo succeed on a clean machine? yes/no [Reproduce] claim -> script -> expected figure present? small-scale mode for missing hardware? yes/no [Fixes before upload] <ordered list>
Stanford REAP × CoPaper.AI · 由斯坦福实证方法论团队精选与维护 访问 copaper.ai 微信:CoPaper.AI 按 11 个主流学科板块覆盖 经管与商科 社会科学 人文学科 数学与物理科学 生命科学 医学与健康 工程与技术 计算机科学与 AI 体育科学 点击任一学科名可跳转到对应说明;每类下的代表子领域在正文总览中完整列出。下方封面墙按 venue 导航,完整分类见覆盖一览。 🧭 布局指南 · 📚 Skill Pack 一览 · ⚡ 如何使用 · 🧪 自动实证
Other skills on awesome-journal-skills.
- /aaai-artifact-evaluation
Use when packaging AAAI code, data, multimedia appendices, technical appendices, reproducibility evidence, and post-acceptance artifact releases without violating double-blind or immutable-supplement rules.
Open skill - /aaai-author-response
Use when drafting an AAAI author response (rebuttal) under the single short character-limited author-feedback window, the no-URL rule, no-new-results guidance, AI-generated-review handling, and the AAAI two-phase review process where Phase-2 papers receive one feedback round
Open skill - /aaai-camera-ready
Use when preparing an accepted AAAI paper for camera-ready source submission to AAAI Press, including proceedings page limits, two-column template compliance, copyright transfer, purchased extra technical pages, deanonymization, registration, oral or poster presentation, and
Open skill - /aaai-experiments
Use when designing or auditing AAAI experiments for the broad-AI program committee, including baselines, ablations, statistical significance, robustness, human evaluation, AI-for-Social-Impact and alignment/safety evidence, compute and cost reporting, and
Open skill - /aaai-related-work
Use when positioning an AAAI paper's novelty against archival work, contemporaneous arXiv or workshop papers, and AAAI/IJCAI/NeurIPS/ICML/ICLR neighbors across the broad AI scope, while staying inside AAAI's dual-submission and AI-as-source policy constraints and writing a
Open skill - /aaai-reproducibility
Use when strengthening an AAAI paper's reproducibility checklist (placed after references), experimental traceability, seed and hyperparameter reporting, compute and cost disclosure, dataset access and licensing, code/data ZIP readiness, and the claim-to-evidence map that
Open skill

