/acl-experiments
Use when designing or auditing experiments for an ACL paper, covering tuned LLM baselines, multi-dataset and multilingual evaluation, statistical significance and variance, human evaluation with agreement reporting, contamination and prompt-sensitivity controls, ablations, and
$ npx -y skills add brycewang-stanford/Awesome-Journal-Skills --skill acl-experiments --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
/acl-experiments
Context preview
The summary Claude sees to decide when to auto-load this skill.
Use when designing or auditing experiments for an ACL paper, covering tuned LLM baselines, multi-dataset and multilingual evaluation, statistical significance and variance, human evaluation with agreement reporting, contamination and prompt-sensitivity controls, ablations, and
SKILL.md
acl-experiments.SKILL.mdname: acl-experiments
description: Use when designing or auditing experiments for an ACL paper, covering tuned LLM baselines, multi-dataset and multilingual evaluation, statistical significance and variance, human evaluation with agreement reporting, contamination and prompt-sensitivity controls, ablations, and error-analysis expectations in NLP reviewing.
ACL Experiments
Use this while the experimental story can still change. The ACL evidence bar is not "beats the baseline once": it is a defensible measurement of a language capability, with the failure modes examined.
Baseline honesty
- Include the strongest cheap baseline: a well-prompted current LLM has become
mandatory context for most tasks — a method beating only pre-LLM systems invites the "does this matter now?" review.
- Tune baselines with the same care as your method (same search budget, same
data); reviewers explicitly probe for asymmetric tuning.
- Report the trivial baselines (majority class, copy input, retrieval-only)
when they contextualize how hard the task actually is.
Evaluation design
- Breadth must match the claim: a "general" claim needs multiple datasets;
a cross-lingual claim needs typologically distinct languages, not three Romance neighbors.
- Automatic metrics need justification for generation tasks — pair n-gram or
embedding metrics with human or LLM-judge evaluation, and validate any LLM-judge against human labels before leaning on it.
- Fix the evaluation protocol before final runs: dev-set peeking on the test
set via repeated submissions is unreportable and unrepairable.
Statistical floor
| Result flavor | Required rigor at ACL | |---|---| | Small deltas between systems | Significance test (bootstrap/permutation) or overlapping-interval honesty | | Fine-tuning results | Multiple seeds; mean and deviation in the table, defined in the caption | | Prompted-LLM results | Multiple prompt paraphrases and/or samples; sensitivity range reported | | Human evaluation | Raters per item, agreement statistic (e.g., Krippendorff's alpha), pay disclosed | | Correlation claims (metrics) | Confidence intervals and comparison against existing metric correlations |
The Responsible NLP checklist (Section C) asks for descriptive statistics and error bars — an experiment plan that cannot fill Section C truthfully is incomplete by construction.
Contamination and validity controls
- Reason explicitly about test-set membership in pretraining data: release
dates vs model cutoffs, overlap scans, or held-back fresh test items.
- Watch prompt leakage: few-shot exemplars drawn from the test distribution,
instructions embedding label hints.
- For annotation-based data, quantify label quality before measuring models
against it; models are now frequently better than noisy gold labels.
Ablations and the mechanism claim
- Each component the abstract credits needs an ablation row; each ablation
row needs the same variance treatment as the headline number.
- Prefer ablations that test the *explanation* (e.g., "gains come from the
retrieval step") over combinatorial component sweeps.
- Scale ablation: if a claim is "method X helps," show it at two model sizes
or state the single-scale limitation explicitly.
Error analysis as a deliverable
The distinctive ACL expectation: a quantitative error analysis with named categories.
1. Sample failures (100-200) from the strongest configuration. 2. Induce 4-8 functional error categories; double-annotate a subset and report agreement. 3. Report category frequencies for your method vs the best baseline — where do gains actually come from? 4. Feed the two most persistent categories into Limitations.
Pre-run design worksheet
Claim: <one sentence>
Datasets: <n, why these, language list>
Baselines: <incl. tuned LLM baseline + trivial floor>
Runs/variance: <seeds or prompt paraphrases; interval type>
Significance: <test, when applied>
Human eval: <items, raters, agreement plan, pay>
Contamination: <audit method>
Ablations: <component -> table row>
Error analysis:<sample size, category plan>
Common evidence failures seen in ARR reviews
- Averaging over languages to hide that one language regressed — report the
per-language block; reviewers open the appendix table first when a claim says "multilingual."
- Comparing your tuned method against baseline numbers copied from papers
that used different preprocessing or splits.
- Treating an LLM judge as ground truth without reporting its agreement
with humans on a calibration subset.
- Claiming efficiency without wall-clock, memory, or cost on matched
hardware.
- Running the significance test only on the comparison that wins.
- Reporting the best seed as the headline and the mean in the appendix —
reviewers call this out by name.
When compute is the constraint
- Pre-register (internally) which single configuration gets the full
multi-seed treatment, and make it the headline setting.
- Use paired designs — same items, both systems — so smaller samples still
yield tight comparisons and permutation tests apply cleanly.
- Prefer breadth at small scale plus depth at one large scale over a thin
sweep of everything; state the choice in the setup section.
- Cache and release intermediate outputs so ablations re-score rather than
re-run.
Output format
[Evidence verdict] convincing / thin / misaligned-with-claim
[Baseline gaps] <missing or under-tuned comparators>
[Statistical gaps] <variance/significance/agreement omissions>
[Validity threats] <contamination/leakage/label-quality>
[Highest-value next run] <one experiment>
Read more
name: acl-experiments description: Use when designing or auditing experiments for an ACL paper, covering tuned LLM baselines, multi-dataset and multilingual evaluation, statistical significance and variance, human evaluation with agreement reporting, contamination and prompt-sensitivity controls, ablations, and error-analysis expectations in NLP reviewing.
ACL Experiments
Use this while the experimental story can still change. The ACL evidence bar is not "beats the baseline once": it is a defensible measurement of a language capability, with the failure modes examined.
Baseline honesty
- Include the strongest cheap baseline: a well-prompted current LLM has become
mandatory context for most tasks — a method beating only pre-LLM systems invites the "does this matter now?" review.
- Tune baselines with the same care as your method (same search budget, same
data); reviewers explicitly probe for asymmetric tuning.
- Report the trivial baselines (majority class, copy input, retrieval-only)
when they contextualize how hard the task actually is.
Evaluation design
- Breadth must match the claim: a "general" claim needs multiple datasets;
a cross-lingual claim needs typologically distinct languages, not three Romance neighbors.
- Automatic metrics need justification for generation tasks — pair n-gram or
embedding metrics with human or LLM-judge evaluation, and validate any LLM-judge against human labels before leaning on it.
- Fix the evaluation protocol before final runs: dev-set peeking on the test
set via repeated submissions is unreportable and unrepairable.
Statistical floor
| Result flavor | Required rigor at ACL | |---|---| | Small deltas between systems | Significance test (bootstrap/permutation) or overlapping-interval honesty | | Fine-tuning results | Multiple seeds; mean and deviation in the table, defined in the caption | | Prompted-LLM results | Multiple prompt paraphrases and/or samples; sensitivity range reported | | Human evaluation | Raters per item, agreement statistic (e.g., Krippendorff's alpha), pay disclosed | | Correlation claims (metrics) | Confidence intervals and comparison against existing metric correlations |
The Responsible NLP checklist (Section C) asks for descriptive statistics and error bars — an experiment plan that cannot fill Section C truthfully is incomplete by construction.
Contamination and validity controls
- Reason explicitly about test-set membership in pretraining data: release
dates vs model cutoffs, overlap scans, or held-back fresh test items.
- Watch prompt leakage: few-shot exemplars drawn from the test distribution,
instructions embedding label hints.
- For annotation-based data, quantify label quality before measuring models
against it; models are now frequently better than noisy gold labels.
Ablations and the mechanism claim
- Each component the abstract credits needs an ablation row; each ablation
row needs the same variance treatment as the headline number.
- Prefer ablations that test the *explanation* (e.g., "gains come from the
retrieval step") over combinatorial component sweeps.
- Scale ablation: if a claim is "method X helps," show it at two model sizes
or state the single-scale limitation explicitly.
Error analysis as a deliverable
The distinctive ACL expectation: a quantitative error analysis with named categories.
1. Sample failures (100-200) from the strongest configuration. 2. Induce 4-8 functional error categories; double-annotate a subset and report agreement. 3. Report category frequencies for your method vs the best baseline — where do gains actually come from? 4. Feed the two most persistent categories into Limitations.
Pre-run design worksheet
Claim: <one sentence> Datasets: <n, why these, language list> Baselines: <incl. tuned LLM baseline + trivial floor> Runs/variance: <seeds or prompt paraphrases; interval type> Significance: <test, when applied> Human eval: <items, raters, agreement plan, pay> Contamination: <audit method> Ablations: <component -> table row> Error analysis:<sample size, category plan>
Common evidence failures seen in ARR reviews
- Averaging over languages to hide that one language regressed — report the
per-language block; reviewers open the appendix table first when a claim says "multilingual."
- Comparing your tuned method against baseline numbers copied from papers
that used different preprocessing or splits.
- Treating an LLM judge as ground truth without reporting its agreement
with humans on a calibration subset.
- Claiming efficiency without wall-clock, memory, or cost on matched
hardware.
- Running the significance test only on the comparison that wins.
- Reporting the best seed as the headline and the mean in the appendix —
reviewers call this out by name.
When compute is the constraint
- Pre-register (internally) which single configuration gets the full
multi-seed treatment, and make it the headline setting.
- Use paired designs — same items, both systems — so smaller samples still
yield tight comparisons and permutation tests apply cleanly.
- Prefer breadth at small scale plus depth at one large scale over a thin
sweep of everything; state the choice in the setup section.
- Cache and release intermediate outputs so ablations re-score rather than
re-run.
Output format
[Evidence verdict] convincing / thin / misaligned-with-claim [Baseline gaps] <missing or under-tuned comparators> [Statistical gaps] <variance/significance/agreement omissions> [Validity threats] <contamination/leakage/label-quality> [Highest-value next run] <one experiment>
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

