| 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:
- 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.
- Why current automation (or manual practice) is inadequate — what existing tools do not do,
stated as a gap, not a literature tour.
- The contribution as an automation design — the technique (analysis, generator, synthesizer,
repair, learned model) and, ideally, the tool that embodies it.
- Evidence on real subjects — real systems, credible tool baselines, and the metric that
matches the task (not a proxy).
- 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?
