/ase-related-work
Use when writing the related-work and positioning of an ASE (IEEE/ACM Automated Software Engineering) paper, covering the automated-SE literature lanes, delta-first positioning against prior tools/techniques, fair head-to-head framing, and double-anonymous self-citation.
$ npx -y skills add brycewang-stanford/Awesome-Journal-Skills --skill ase-related-work --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
/ase-related-work
Context preview
The summary Claude sees to decide when to auto-load this skill.
Use when writing the related-work and positioning of an ASE (IEEE/ACM Automated Software Engineering) paper, covering the automated-SE literature lanes, delta-first positioning against prior tools/techniques, fair head-to-head framing, and double-anonymous self-citation.
SKILL.md
ase-related-work.SKILL.mdname: ase-related-work
description: Use when writing the related-work and positioning of an ASE (IEEE/ACM Automated Software Engineering) paper, covering the automated-SE literature lanes, delta-first positioning against prior tools/techniques, fair head-to-head framing, and double-anonymous self-citation.
ASE Related Work
Position the paper against **prior automation**, not against a topic. At ASE the question a reviewer holds is "what does this tool/technique do that the existing automated approaches do not?" — so related work is a **delta argument**, and the strongest deltas are stated against named, runnable prior tools you can (and often must) compare against empirically.
Cover the ASE literature lanes
An automated-SE paper usually sits at the intersection of several lanes; name your position in each that applies:
- **Program analysis** — static/dynamic analysis, symbolic/concolic execution, abstract
interpretation, invariant inference.
- **Test generation and testing** — search-based, specification-based, fuzzing, regression and
flaky-test handling.
- **Fault localization, debugging, and repair** — spectrum-based localization, automated program
repair, patch synthesis.
- **Synthesis and recommendation** — program/code synthesis, API recommendation, refactoring
automation.
- **Comprehension and documentation** — summarization, code search, clone and change analysis.
- **Learning-based / AI4SE** — learned code representations, models applied to SE tasks, LLM-based
automation — and **SE4AI**, applying SE automation to ML systems.
Delta-first positioning
Write each related-work cluster as: *prior automation X does A; it cannot do B because C; we do B.* Then, where B is comparable, **compare against X empirically** — ASE reviewers expect a head-to-head against the closest runnable baseline, not just a prose distinction.
[Cluster] spectrum-based fault localization
Prior: ranks statements by suspiciousness from pass/fail spectra.
Gap: assumes a fixed test suite; degrades when tests are flaky.
Delta: our technique estimates and corrects for flakiness before ranking.
Evidence of delta: head-to-head on the same faulty subjects, §5.2, Table 3.
Fair head-to-head framing (the ASE credibility test)
- Compare against the **strongest, most recent** automated baseline you can run, at an **equal,
documented budget** (time, iterations, tuning). An under-configured baseline is the classic soundness objection and a Revision criterion waiting to happen.
- If a baseline tool cannot run on your subjects, say why explicitly and choose the nearest viable
alternative — do not quietly omit the obvious competitor.
- Distinguish **reimplementation** from the original tool, and note version/commit — reviewers who
built the baseline will check.
Distinguish ASE from sibling-venue prior work
Because automated-SE ideas appear across venues, position precisely: a testing-theory result may live at ISSTA, a broad empirical study at FSE, a language mechanism at a PL venue. When you cite across venues, make the ASE delta — *the automation you add* — explicit, so a reviewer does not read your contribution as a reheated sibling-venue result.
Double-anonymous self-citation
- Cite your own prior tools and papers in the **third person** ("Prior work by [Anonymous] proposed
...", or neutrally "The X tool [12] ...") so the citation does not deanonymize you.
- Do not write "our earlier tool" or link to a repository whose owner is you.
- Keep the count of self-citations honest; a cluster of third-person citations to one hidden group
is itself a leak.
Coverage checks
[Recency] at least the last 2-3 years of ASE/ICSE/FSE/ISSTA automation in your subarea cited?
[Closest baseline] is the single most similar runnable tool named AND compared, not just cited?
[Cross-venue] PL/ML/testing neighbors positioned so your automation delta is explicit?
[Anonymity] every self-citation in the third person; no repository ownership revealed?
[Honesty] any obvious competitor conspicuously missing? (a reviewer will notice)
Output format
[Lanes] which automated-SE lanes the paper touches
[Delta table] prior tool -> what it does -> gap -> your delta -> where the head-to-head lives
[Baseline fairness] closest runnable baseline named, version pinned, equal budget?
[Anonymity check] self-citations third-person, no repo owner revealed
Read more
name: ase-related-work description: Use when writing the related-work and positioning of an ASE (IEEE/ACM Automated Software Engineering) paper, covering the automated-SE literature lanes, delta-first positioning against prior tools/techniques, fair head-to-head framing, and double-anonymous self-citation.
ASE Related Work
Position the paper against **prior automation**, not against a topic. At ASE the question a reviewer holds is "what does this tool/technique do that the existing automated approaches do not?" — so related work is a **delta argument**, and the strongest deltas are stated against named, runnable prior tools you can (and often must) compare against empirically.
Cover the ASE literature lanes
An automated-SE paper usually sits at the intersection of several lanes; name your position in each that applies:
- **Program analysis** — static/dynamic analysis, symbolic/concolic execution, abstract
interpretation, invariant inference.
- **Test generation and testing** — search-based, specification-based, fuzzing, regression and
flaky-test handling.
- **Fault localization, debugging, and repair** — spectrum-based localization, automated program
repair, patch synthesis.
- **Synthesis and recommendation** — program/code synthesis, API recommendation, refactoring
automation.
- **Comprehension and documentation** — summarization, code search, clone and change analysis.
- **Learning-based / AI4SE** — learned code representations, models applied to SE tasks, LLM-based
automation — and **SE4AI**, applying SE automation to ML systems.
Delta-first positioning
Write each related-work cluster as: *prior automation X does A; it cannot do B because C; we do B.* Then, where B is comparable, **compare against X empirically** — ASE reviewers expect a head-to-head against the closest runnable baseline, not just a prose distinction.
[Cluster] spectrum-based fault localization Prior: ranks statements by suspiciousness from pass/fail spectra. Gap: assumes a fixed test suite; degrades when tests are flaky. Delta: our technique estimates and corrects for flakiness before ranking. Evidence of delta: head-to-head on the same faulty subjects, §5.2, Table 3.
Fair head-to-head framing (the ASE credibility test)
- Compare against the **strongest, most recent** automated baseline you can run, at an **equal,
documented budget** (time, iterations, tuning). An under-configured baseline is the classic soundness objection and a Revision criterion waiting to happen.
- If a baseline tool cannot run on your subjects, say why explicitly and choose the nearest viable
alternative — do not quietly omit the obvious competitor.
- Distinguish **reimplementation** from the original tool, and note version/commit — reviewers who
built the baseline will check.
Distinguish ASE from sibling-venue prior work
Because automated-SE ideas appear across venues, position precisely: a testing-theory result may live at ISSTA, a broad empirical study at FSE, a language mechanism at a PL venue. When you cite across venues, make the ASE delta — *the automation you add* — explicit, so a reviewer does not read your contribution as a reheated sibling-venue result.
Double-anonymous self-citation
- Cite your own prior tools and papers in the **third person** ("Prior work by [Anonymous] proposed
...", or neutrally "The X tool [12] ...") so the citation does not deanonymize you.
- Do not write "our earlier tool" or link to a repository whose owner is you.
- Keep the count of self-citations honest; a cluster of third-person citations to one hidden group
is itself a leak.
Coverage checks
[Recency] at least the last 2-3 years of ASE/ICSE/FSE/ISSTA automation in your subarea cited? [Closest baseline] is the single most similar runnable tool named AND compared, not just cited? [Cross-venue] PL/ML/testing neighbors positioned so your automation delta is explicit? [Anonymity] every self-citation in the third person; no repository ownership revealed? [Honesty] any obvious competitor conspicuously missing? (a reviewer will notice)
Output format
[Lanes] which automated-SE lanes the paper touches [Delta table] prior tool -> what it does -> gap -> your delta -> where the head-to-head lives [Baseline fairness] closest runnable baseline named, version pinned, equal budget? [Anonymity check] self-citations third-person, no repo owner revealed
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

