Skip to content
cccskills
FreePublished on GitHub

acl-artifact-evaluation

Use when packaging code, datasets, prompts, model outputs, or annotation materials for an ACL submission under ACL Rolling Review, covering anonymized supplement archives, scientific-artifact items of the Responsible NLP checklist, licensing and intended-use documentation, data statements, and post-acceptance public release.

The English summary is being prepared. Showing the original description.

See how to install

Files included (1)

  • SKILL.md5.7 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

ACL Artifact Evaluation

Use this to plan the evidence package around an ACL paper. ACL has no separate artifact-badge track; instead, artifact scrutiny is folded into review through the supplement archive and Section B ("scientific artifacts") of the Responsible NLP checklist, which reviewers cross-check against the PDF.

What counts as an artifact here

  • Code: training/inference scripts, evaluation harnesses, prompt templates.
  • Data: new corpora, annotations, filtered subsets of existing corpora, test suites, adversarial sets.
  • Model outputs: generations, ranked lists, logits used in analysis — often the cheapest way to make an LLM paper checkable without GPUs.
  • Human-subject materials: annotation guidelines, interface screenshots, consent text, compensation description.

Submission-time packaging rules

  • Supplements upload as .tgz/.zip through the OpenReview form; links to tracked cloud storage are not acceptable, and any linked page must be anonymous.
  • Scrub identity everywhere reviewers can look: file paths, git metadata, notebook author fields, license headers, dataset hosting pages, README contact lines.
  • Reviewers are not required to open supplements. The paper plus checklist must stand alone; the archive is for verification, not for essential content.

Checklist items your artifact must satisfy

Responsible NLP item (Section B)Artifact implication
Cited creators + versions of used artifactsPin dataset/model versions in the README and bibliography
License / terms of use statedInclude the license you release under and those you consumed under
Use consistent with intended useJustify research use of scraped or user-generated data
PII and offensive content handledDescribe scanning/anonymization steps actually performed
Documentation of domains, languages, demographicsShip a data statement or datasheet, not just row counts
Statistics on splits reportedTrain/dev/test sizes in both paper and README

Checklist answers contradicted by the archive read as misleading information — grounds for desk rejection under ARR policy, and a credibility wound even when not enforced.

What an ACL reviewer opens first

  1. The README — it has roughly one minute to orient them.
  2. Prompt files and evaluation scripts, for any LLM claim: exact prompts, decoding parameters, and scoring code are the reproduction spine.
  3. Annotation guidelines, for any dataset or human-eval claim: reviewers judge whether the labels could possibly mean what the paper says.
  4. A sample of the data itself — quality problems visible in twenty random examples have sunk otherwise strong resource papers.

Vignette: packaging a multilingual benchmark submission

A hypothetical paper releases a 7-language reading-comprehension test suite built from news text plus a baseline evaluation of five LLMs.

  • Ship per-language provenance: source, license, collection window, and the filtering pipeline as runnable code, since "web text" alone fails checklist item B on documentation.
  • Include annotator guidelines, pay, recruitment channel, and agreement statistics; multilingual annotation quality is the first attack surface.
  • Provide the exact prompts and outputs for all five models so reviewers can re-score without API keys.
  • Keep a versioned, hash-stamped test file so post-publication contamination can be audited later.

Release ladder after acceptance

anonymous supplement  ->  public repo + dataset page  ->  archived, versioned release
   (review-time)          (camera-ready links)            (DOI/hub artifact, cited version)

Post-acceptance, register the artifact where your community actually looks (model/dataset hubs, a maintained repo), state the license explicitly, and put the citation-of-record (the Anthology entry) in the README.

Anonymization sweep, concretely

Run these before zipping, on a copy:

# authorship trails in code and docs
grep -ri "yourname\|yourlab\|university" . --include="*.py" --include="*.md"
# git history and remotes leak owners
rm -rf .git; # or re-init a fresh repo for the archive copy
# notebook metadata carries usernames and kernel paths
jupyter nbconvert --clear-output --inplace *.ipynb
# absolute paths in configs and logs
grep -r "/home/\|/Users/" . | head

Then check the parts tools miss: license headers naming the lab, dataset hosting pages with institutional branding, model cards listing maintainers, and README badges pointing at owner-named CI.

Sizing and format sanity

  • Keep the archive lean: strip checkpoints reviewers cannot load anyway, cached datasets, and virtualenvs; describe big assets and provide them at camera-ready instead.
  • One top-level README, one environment file, one entry point per claimed result — reviewers grant roughly a minute before giving up.
  • Verify the .zip/.tgz opens on a machine that has never seen the project; OpenReview upload limits and accepted fields vary by cycle, so check the live form rather than last cycle's.

Output format

[Artifact role] anonymous supplement / camera-ready release / public benchmark
[Contents] <code/data/prompts/outputs/guidelines>
[Checklist alignment] <Section B items satisfied vs missing>
[Anonymity findings] <paths/metadata/hosting leaks>
[Release plan] <post-acceptance registry, license, versioning>

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

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.

The English summary is being prepared. Showing the original description.

brycewang-stanford/Awesome-Journal-Skills1.3KUpdated Sep 27, 2026

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 before SPC/AC discussion.

The English summary is being prepared. Showing the original description.

brycewang-stanford/Awesome-Journal-Skills1.3KUpdated Sep 27, 2026

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 final public artifact release.

The English summary is being prepared. Showing the original description.

brycewang-stanford/Awesome-Journal-Skills1.3KUpdated Sep 27, 2026

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 reproducibility-checklist alignment for Phase-1 survival.

The English summary is being prepared. Showing the original description.

brycewang-stanford/Awesome-Journal-Skills1.3KUpdated Sep 27, 2026

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 related-work section legible to non-specialist reviewers.

The English summary is being prepared. Showing the original description.

brycewang-stanford/Awesome-Journal-Skills1.3KUpdated Sep 27, 2026

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 Phase-1 reviewers use to judge rigor across AAAI's broad AI scope.

The English summary is being prepared. Showing the original description.

brycewang-stanford/Awesome-Journal-Skills1.3KUpdated Sep 27, 2026

See all skills by brycewang-stanford

Report a problem with this skill