---

name: ase-writing-style description: Use when shaping the prose and structure of an ASE (IEEE/ACM Automated Software Engineering) research paper, covering the automation-first first-page arc, stating the automated task precisely, keeping the tool runnable and the model-swap test in mind, threats-as-argument, and the 10+2 page discipline on the ACM acmart template.

ASE Writing Style

Write the paper so an automated-SE reviewer sees, on the first page, what task you automate, how you automate it, and that it runs on real subjects. ASE rewards a clearly stated automation with evidence proportional to the claim — not a systems win, not a leaderboard, and not a broad finding that would read better at FSE. The worked example in resources/worked-examples/01-introduction.md shows the arc before → after.

The ASE first-page arc

Lead with the automation, in this order:

1. The automatable task — a software-engineering task the reader recognizes (detect X, generate Y, repair Z, comprehend W), named precisely enough that a reviewer knows what "success" is.
2. Why current automation (or manual practice) is inadequate — what existing tools do not do, stated as a gap, not a literature tour.
3. The contribution as an automation design — the technique (analysis, generator, synthesizer, repair, learned model) and, ideally, the tool that embodies it.
4. Evidence on real subjects — real systems, credible tool baselines, and the metric that matches the task (not a proxy).
5. What it automates for practice + threats posture — the payoff, with the central threat named where it lives, not deferred to a closing paragraph.

Put the automation and the first evidence within the first three pages; the early-rejection gate means a weak opening can end the process before rebuttal.

State the automated task precisely

• Name the input, the output, and the success criterion of the automation. "We improve code quality" is not a task; "given a flaky test, synthesize a patch that makes it deterministic without weakening its assertions" is.
• Say what the tool takes as input in practice (source? bytecode? traces? a repository?) and what it produces — reviewers map this straight to feasibility.

Keep the model-swap test in view

If a learned component is involved, write so the automation design is the contribution, not the model. Report an ablation that isolates the learned part from the analysis/oracle, and phrase claims so the software-engineering lesson survives a model swap. A paper whose lesson evaporates when the model changes reads as an ML re-route (see ase-topic-selection).

Evidence proportional to the claim

• A detection claim needs precision/recall on real defects with a defined ground truth.
• A generation/synthesis claim needs validity of the generated artifact (does it compile, pass, hold the property?), not just similarity to a reference.
• A repair claim needs verified behavior change (re-run, oracle), not a classification score.
• A speed/scalability claim needs real-system sizes and a fair baseline configuration.

Pair every claim in the abstract with a table or figure it points to. Match evidence to claim shape; see ase-experiments.

Threats as argument, not boilerplate

Argue construct, internal, and external validity where they arise. For automated-SE tools the usual suspects: the oracle (how do you know a "repair" is correct?), subject selection (are the systems representative or self-selected?), baseline fairness (equal budgets/tuning?), and overfitting to the evaluation set. Name the residual threat plainly and bound it (an audited subsample, a held-out subject set) rather than reciting a checklist.

Page-budget discipline (10 + 2)

• 10 pages for everything readable — text, figures, tables, appendices — plus 2 for references only. The mandatory Data Availability Statement after Conclusions counts inside the 10 pages.
• Recover space editorially, not by shrinking the template. Move reproducible detail (full configs, extra tables, proofs) to the artifact, but nothing that decides acceptance may live outside the body (see ase-supplementary).
• Figures earn their space by carrying an argument (the automation's pipeline, a per-root-cause breakdown), not by decorating it.

Prose conventions

• Present tense for what the tool does; past tense for what you did in the study.
• Name the tool once, early, and use it consistently (anonymized at submission).
• Prefer concrete verbs of automation — detects, synthesizes, localizes, repairs, infers — over vague ones like leverages or explores.
• Third-person self-citation throughout, for double-anonymity.

Common ASE writing failures

| Failure | Why it hurts at ASE | Fix | |---|---|---| | Model/leaderboard framing | Reads as ML, not automated SE | Foreground the automation design; add the ablation | | Vague task statement | Reviewer cannot judge success | Give input/output/success criterion in ¶1 | | Proxy-metric evaluation | Evidence does not match a repair/synthesis claim | Verify the produced artifact directly (re-run/oracle) | | Threats as a closing recital | Construct/oracle validity never engaged | Argue each threat where it arises; bound it | | Body over 10 pages | Desk-reject-grade | Move reproducible detail to the artifact |

Output format

[Task] input -> output -> success criterion (one sentence, on page 1?)
[Automation-first arc] task / inadequacy / technique+tool / real-subject evidence / payoff+threats — all present?
[Model-swap] ablation isolating the learned component present? lesson survives a model swap?
[Evidence-claim pairing] each abstract claim -> a table/figure with a matching metric
[Budget] content pages / reference pages / Data Availability inside 10pp?