/ase-reproducibility
Use when building the open-science and reproducibility story for an ASE (IEEE/ACM Automated Software Engineering) submission, covering the mandatory Data Availability Statement, anonymized-but-runnable tools, tool and subject-system provenance pinning, cached LLM outputs, and
$ npx -y skills add brycewang-stanford/Awesome-Journal-Skills --skill ase-reproducibility --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
/ase-reproducibility
Context preview
The summary Claude sees to decide when to auto-load this skill.
Use when building the open-science and reproducibility story for an ASE (IEEE/ACM Automated Software Engineering) submission, covering the mandatory Data Availability Statement, anonymized-but-runnable tools, tool and subject-system provenance pinning, cached LLM outputs, and
SKILL.md
ase-reproducibility.SKILL.mdname: ase-reproducibility
description: Use when building the open-science and reproducibility story for an ASE (IEEE/ACM Automated Software Engineering) submission, covering the mandatory Data Availability Statement, anonymized-but-runnable tools, tool and subject-system provenance pinning, cached LLM outputs, and staging for the ACM Available/Reusable artifact badges.
ASE Reproducibility
Build the reproducibility story at data-collection time, not at submission. ASE requires a **mandatory Data Availability Statement** in the paper and expects an **anonymized, runnable** artifact at review time; automated-SE artifacts are usually *tools*, so "runnable" means a reviewer can actually execute the automation on stated subjects. What is not pinned when you collect it cannot be reconstructed later.
The mandatory Data Availability Statement
- **Required**, placed **after the Conclusions** and **inside the 10-page limit** (it is not free
appendix space).
- State what exists — the tool, the dataset, the subject systems, the scripts, the logs — and
**where it will live** after acceptance (an archival DOI target).
- Provide an **anonymized** link or upload now; "available upon request" reads as a scored weakness,
not a neutral placeholder.
- Match the statement to what the archive actually contains — an overclaiming statement is worse
than a modest, honest one.
Anonymized-but-runnable tools
- Re-host the tool and dataset behind an **anonymizing service**; strip repository owner, commit
author metadata, and any path revealing your identity (`/home/<you>/`, institutional URLs).
- Include a **minimal run path**: exact commands, expected inputs, and a small sample so a reviewer
can execute the automation without your machine.
- Pin the environment: dependencies with versions, a container or lockfile, and the exact tool
commit — automated-SE tools rot fast against moving toolchains.
Provenance pinning (do this at collection time)
For the tool:
- Exact **commit SHA**, build instructions, dependency versions, and configuration/flags used in the
experiments (including seeds for randomized components).
For subject systems and datasets:
- **Names, versions, and SHAs** of every subject; the corpus **extraction date**; query/filter
criteria; and any manual **labeling protocol** with inter-rater agreement.
- A regeneration script and a versioned snapshot — live scraping re-samples a moving target.
For LLM-based components:
- **Model identifiers and dates**, prompts, decoding settings, and **cached raw outputs** so the
artifact reproduces rather than calls a live, drifting API.
Reproducibility failure modes (ASE-specific)
| Failure | Consequence | Prevention | |---|---|---| | Tool needs your exact machine | Reviewers cannot run it; artifact fails | Container/lockfile + minimal run path | | Subjects unpinned (branch, not SHA) | Numbers cannot be reproduced | Record SHAs + extraction date at collection | | LLM outputs uncached | Re-runs drift; comparison invalid | Cache outputs; record model IDs/dates | | Data Availability outside the 10 pages | Policy violation | Place it after Conclusions, inside the budget | | Identity leak in artifact | Anonymity violation | Scrub owner/metadata; re-host anonymized |
From submission to the ACM badges
The submission-time artifact and the post-acceptance badge artifact are the *same package* matured. ASE offers **Artifacts Available** and **Artifacts Reusable** badges (ACM scheme); staging for them now avoids a scramble later (see `ase-artifact-evaluation`):
- **Available** — deposit in a DOI-issuing archive (Zenodo / figshare / Software Heritage) with an
open license.
- **Reusable** — documentation, a clear run path, and structure that lets a stranger reuse the tool
beyond reproducing your tables.
Output format
[Data Availability] present, after Conclusions, inside 10pp? matches the archive?
[Tool] commit pinned, deps versioned, container/lockfile, minimal run path?
[Subjects/data] SHAs + extraction date + selection/labeling protocol recorded?
[LLM] model IDs/dates, prompts, cached outputs?
[Anonymity] owner/metadata scrubbed; anonymized re-host?
[Badge readiness] Available (DOI+license) / Reusable (docs+run path) staged?
Read more
name: ase-reproducibility description: Use when building the open-science and reproducibility story for an ASE (IEEE/ACM Automated Software Engineering) submission, covering the mandatory Data Availability Statement, anonymized-but-runnable tools, tool and subject-system provenance pinning, cached LLM outputs, and staging for the ACM Available/Reusable artifact badges.
ASE Reproducibility
Build the reproducibility story at data-collection time, not at submission. ASE requires a **mandatory Data Availability Statement** in the paper and expects an **anonymized, runnable** artifact at review time; automated-SE artifacts are usually *tools*, so "runnable" means a reviewer can actually execute the automation on stated subjects. What is not pinned when you collect it cannot be reconstructed later.
The mandatory Data Availability Statement
- **Required**, placed **after the Conclusions** and **inside the 10-page limit** (it is not free
appendix space).
- State what exists — the tool, the dataset, the subject systems, the scripts, the logs — and
**where it will live** after acceptance (an archival DOI target).
- Provide an **anonymized** link or upload now; "available upon request" reads as a scored weakness,
not a neutral placeholder.
- Match the statement to what the archive actually contains — an overclaiming statement is worse
than a modest, honest one.
Anonymized-but-runnable tools
- Re-host the tool and dataset behind an **anonymizing service**; strip repository owner, commit
author metadata, and any path revealing your identity (`/home/<you>/`, institutional URLs).
- Include a **minimal run path**: exact commands, expected inputs, and a small sample so a reviewer
can execute the automation without your machine.
- Pin the environment: dependencies with versions, a container or lockfile, and the exact tool
commit — automated-SE tools rot fast against moving toolchains.
Provenance pinning (do this at collection time)
For the tool:
- Exact **commit SHA**, build instructions, dependency versions, and configuration/flags used in the
experiments (including seeds for randomized components).
For subject systems and datasets:
- **Names, versions, and SHAs** of every subject; the corpus **extraction date**; query/filter
criteria; and any manual **labeling protocol** with inter-rater agreement.
- A regeneration script and a versioned snapshot — live scraping re-samples a moving target.
For LLM-based components:
- **Model identifiers and dates**, prompts, decoding settings, and **cached raw outputs** so the
artifact reproduces rather than calls a live, drifting API.
Reproducibility failure modes (ASE-specific)
| Failure | Consequence | Prevention | |---|---|---| | Tool needs your exact machine | Reviewers cannot run it; artifact fails | Container/lockfile + minimal run path | | Subjects unpinned (branch, not SHA) | Numbers cannot be reproduced | Record SHAs + extraction date at collection | | LLM outputs uncached | Re-runs drift; comparison invalid | Cache outputs; record model IDs/dates | | Data Availability outside the 10 pages | Policy violation | Place it after Conclusions, inside the budget | | Identity leak in artifact | Anonymity violation | Scrub owner/metadata; re-host anonymized |
From submission to the ACM badges
The submission-time artifact and the post-acceptance badge artifact are the *same package* matured. ASE offers **Artifacts Available** and **Artifacts Reusable** badges (ACM scheme); staging for them now avoids a scramble later (see `ase-artifact-evaluation`):
- **Available** — deposit in a DOI-issuing archive (Zenodo / figshare / Software Heritage) with an
open license.
- **Reusable** — documentation, a clear run path, and structure that lets a stranger reuse the tool
beyond reproducing your tables.
Output format
[Data Availability] present, after Conclusions, inside 10pp? matches the archive? [Tool] commit pinned, deps versioned, container/lockfile, minimal run path? [Subjects/data] SHAs + extraction date + selection/labeling protocol recorded? [LLM] model IDs/dates, prompts, cached outputs? [Anonymity] owner/metadata scrubbed; anonymized re-host? [Badge readiness] Available (DOI+license) / Reusable (docs+run path) staged?
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

