Skip to content
cccskills
FreePublished on GitHub

acl-writing-style

Use when revising an ACL paper for computational-linguistics house style, covering task-first framing, linguistic examples tied to quantitative error analysis, scoping language claims to tested languages, LLM-era claim discipline, anonymous self-reference, Limitations prose, and compressing into the 8-page or 4-page ACL format.

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

Run score Not tested

See how to install

Files included (1)

  • SKILL.md5.6 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

ACL Writing Style

Use this on the manuscript itself. ACL reviewers are NLP specialists who read for whether the paper understands language as well as models; the style that survives them is concrete, example-grounded, and precisely scoped.

First-page contract

  • Open with the task or linguistic phenomenon, not the model family: what goes in, what comes out, why it is hard, and for whom.
  • State the contribution as a typed claim by paragraph two: new method, new resource, new analysis, or new finding — ACL reviews are calibrated per type.
  • Give one real example (input, desired output, failure of the status quo) on page one; abstract problem statements without an example read as vague at this venue.
  • Say what languages the paper covers in the abstract if the answer is not "English only" — and if it is, say that too.

Claim scoping in the LLM era

Reflex phrasingACL-safe phrasing
"LLMs cannot do X""The five models tested fail X under these prompts"
"Our method understands Y""Improves the Y benchmark by n points; error classes A, B shrink"
"Works across languages""Evaluated on de/hi/sw/zh/ar; typological coverage discussed in §7"
"Significantly better"Reserve for tested significance; give the test and p-value or interval
"State-of-the-art"Scope to the exact setting, model scale, and date checked

Reviewers increasingly ask whether a result is a property of the task, the model snapshot, or the prompt; write so each claim names which.

Examples and error analysis as prose

  • Every qualitative example must be attached to a number: how often the illustrated behavior occurs, in which slice, under which condition. Cherry-picked generations presented as evidence is a named reject pattern.
  • Use interlinear glosses or transliteration conventions correctly for non-English examples; sloppy linguistics costs credibility with exactly the reviewers who like the paper's topic.
  • Name error categories functionally ("negation-scope errors") rather than narratively ("the model gets confused").

Anonymity-compatible voice

  • Write self-reference in third person: "Smith (2024) introduced X," never "In our previous work." Keep it in place until camera-ready.
  • Do not cite "anonymous (under review)" material that reviewers cannot read; ARR bars relying on documents unavailable to them.
  • Acknowledgements, funding, and AI-assistance credits are omitted at submission and added at camera-ready.

Compression into 8 (or 4) pages

  • The short-paper form is a single sharp point with one strong experiment — do not shrink a long paper into four pages; re-argue it.
  • Push prompt dumps, per-language tables, and hyperparameter grids to the appendix; keep one summary row of each in the body (see acl-supplementary).
  • Kill the related-work-as-inventory section; two paragraphs of positioned contrast beat a page of citations (see acl-related-work).
  • Figures earn their space only when they carry an argument — pipeline diagrams restating the text are the first cut.

Limitations and ethics prose

  • Write Limitations as the referee brief against yourself: scope, data coverage, model dependence, evaluation validity. Specificity here is protected — ACL instructs reviewers not to penalize honest limitations.
  • The optional ethics statement is for real stakes: human data, dual use, representational harm. A boilerplate ethics paragraph is worse than none.

Micro-edit pass

weak:   "We leverage powerful LLMs to achieve impressive gains."
strong: "Reranking with a 7B model cuts negation-scope errors from
         31% to 12% of sampled failures (Table 4)."

weak:   "Performance is good across all settings."
strong: "Gains hold on 4 of 5 languages; Swahili degrades (-1.2 F1),
         which §7 traces to tokenizer fragmentation."

Terminology and notation discipline

  • Pick one name per concept and hold it: a system called "our reranker," "the verifier," and "the LLM judge" in three sections reads as three systems to a tired reviewer.
  • Define task-specific terms at first use, even standard-seeming ones — "hallucination," "faithfulness," and "robustness" each have three incompatible literatures behind them.
  • Dataset names get their citation at first mention and exact split names thereafter ("XNLI dev-matched," not "the dev set").
  • Numbers in prose match tables to the decimal; reviewers diff them.
  • Language codes: introduce once (ISO 639), then use consistently in tables, figures, and prose alike.

Section-level failure smells

  • An introduction with no example → underspecified task (fix first).
  • A method section narrating engineering chronology ("we first tried...") → rewrite as design with rationale.
  • A results section that re-reads the table aloud → replace with claims the table supports plus pointers into it.
  • A conclusion introducing new claims → move them into results or delete; ACL reviewers treat conclusions as summaries under oath.

Output format

[Style diagnosis] task-first / model-first / survey-ish / underspecified
[First-page fix] <one concrete rewrite>
[Overclaim list] <claim -> scoped version>
[Example-evidence gaps] <anecdotes lacking counts>
[Compression plan] <cut / move / merge>

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