icse-related-work
GitHub指导撰写ICSE论文相关工作章节，覆盖五大文献领域及多数据库检索，强调LLM4SE等前沿领域的时效性，并提供以差异为核心的论证写作模板。
Trigger Scenarios
Install
npx skills add brycewang-stanford/Awesome-Journal-Skills --skill icse-related-work -g -y
SKILL.md
Frontmatter
{
"name": "icse-related-work",
"description": "Use when building the related-work and positioning sections of an ICSE research-track paper, covering the literature lanes SE reviewers check, searching ACM DL, IEEE Xplore and dblp across the flagship venues, staying current in fast-moving areas like LLM4SE, and keeping self-citations double-anonymous."
}
ICSE Related Work
Positioning at ICSE is scored twice: once under novelty ("sufficiently original with respect to the state-of-the-art", per the 2027 criteria read 2026-07-08) and once implicitly when the assigned reviewers — likely authors of the nearest prior work — check whether they and their neighbors are represented fairly. Cover the lanes below before writing a word of the section.
The five lanes an SE reviewer sweeps
| Lane | Where it lives | What missing it costs you |
|---|---|---|
| Flagship conference line | ICSE, FSE, ASE, ISSTA proceedings (ACM DL / IEEE Xplore) | The direct-competitor omission — often the reviewer's own paper |
| Journal line | TSE, TOSEM, EMSE | Mature versions of "your" idea; journals often published it first |
| Specialized venue line | MSR, ICSME, ICPC, SANER, RE, SPLC, ESEM per subfield | Reviewers from that subcommunity notice instantly |
| Preprint line | arXiv cs.SE (critical in LLM4SE, AI-for-SE) | Staleness: in fast lanes, six months of preprints can contain your contribution |
| Adjacent-field line | PL (PLDI/OOPSLA), systems, ML, HCI as relevant | Reinvention accusations from cross-listed reviewers |
Search all three indexes — ACM Digital Library, IEEE Xplore, and dblp — because ICSE's own proceedings historically alternate between publishers and no single index has everything; dblp is the neutral spine for coverage checking, the DLs for full text.
Currency in fast lanes
LLM4SE and AI-for-SE turn over in months. For a June 30 submission, run a final sweep in the last two weeks: new arXiv postings, the just-published ICSE/FSE proceedings, and the accepted-papers lists that venues post before official publication. Concurrent work (public after your study was designed) deserves acknowledgment, not competition: cite it, mark it concurrent, and do not contort your evaluation to beat a paper that appeared last month — reviewers understand timelines and respect the candor.
Writing the section as an argument
The section's job is a delta statement, not a bibliography. Organize by the dimensions on which you differ, then place each cluster:
## Related Work (delta-first pattern)
**Test-suite-based repair.** [Cluster: GenProg lineage, semantics-based
repair.] These validate candidate patches against the failing suite; all
inherit test-suite overfitting. *We differ:* our oracle is X, so overfitting
of type Y cannot occur by construction (§4).
**LLM-based patch generation.** [Cluster: 2023–2026 line, incl. concurrent
work.] These generate candidates but keep suite-based validation. *We
differ:* evaluation on post-training-cutoff bugs (§5.2) removes the
contamination confound these papers share.
**Empirical studies of overfitting.** [Studies motivating the problem.]
We *build on* their measurement protocol and extend it to Z.
Every cluster paragraph ends with the difference stated in your paper's own technical terms, with a section pointer. If a cluster ends with "...has also studied this area", it is filler.
Double-anonymous self-citation
ICSE reviews double-anonymously, and prior-work references must be third person: "Prior work introduced FOO [12]" rather than "In our earlier paper [12]". The subtle leaks: citing an unpublished technical report only your group could know, an artifact URL from your prior paper's repository, and a tool name unique to your lab used without citation. If the current paper extends your own published tool, cite it in third person and phrase the relationship symmetrically ("extends FOO [12] by...") — reviewers may guess, but the text must not confirm.
The nearest-neighbor rehearsal
Before freezing the section, run one simulation: pick the three papers a PC chair would most plausibly assign as reviewer expertise matches — usually the three you compare against in the evaluation — and reread your section as each of those authors. For each, answer: is my paper described accurately (not straw-manned)? is the difference stated in terms I would accept? is my most recent relevant paper present, or only my old one? A misdescribed neighbor produces the angriest review in the packet, and it is entirely preventable at the cost of an hour.
Verification discipline for the bibliography
- Every citation checked against dblp or the DL record — titles, venues, years drift when copied from other papers' bibliographies or generated by models; a hallucinated reference discovered by a reviewer poisons trust in everything else.
- Cite the archival version over the preprint when both exist; keep arXiv IDs for preprint-only work.
- Distinguish venue tiers honestly: a workshop paper and an ICSE paper by the same authors are different maturity claims.
- Normalize venue naming (e.g., ESEC/FSE vs FSE across years) so reviewers recognize the venues at a glance.
Output format
[Lane coverage] five lanes -> swept on <date> / gap
[Delta table] nearest neighbors -> difference in our terms -> section pointer
[Currency] last sweep date; concurrent-work items flagged
[Anonymity] self-citation phrasing audit: violations found/fixed
[Bibliography hygiene] unverified entries remaining (must be zero)
Version History
- 9f86f09 Current 2026-07-19 15:58
