ASPLOS Related Work
SkillProductivityThis skill guides your AI in writing the related-work section of an ASPLOS paper. It positions your submission against the architecture, operating systems, and programming-languages/compiler literatures at the same time, while applying the 2027 double-blind and citation rules. The outcome is a related-work section that covers the right communities and formats references correctly.
Available today. Use it from your connected AI after setup.
No other account needed.
After adding the skill, give your AI your ASPLOS submission and the papers you want compared. It will draft the related-work section across the three literatures while following the double-blind and citation rules.
Then ask your AI: use the ASPLOS Related Work skill
What your AI can do with it
- Position an ASPLOS submission against the architecture, OS/systems, and programming-languages/compiler literatures
- Cover the accelerator and prior-ASPLOS lines of related work
- Handle own-work and arXiv material under the 2027 double-blind rules
- Meet the full-name and DOI citation requirements for ASPLOS
What this skill tells your AI
The instructions your AI receives, as published by brycewang-stanford/awesome-journal-skills in ASPLOS-Skills/skills/asplos-related-work/SKILL.md and read by ahel’s review.
An ASPLOS reviewer pool is assembled from three communities, and each reviewer checks whether their literature is handled competently. Related work at this venue is therefore a coverage problem across parallel lanes — a paper positioned beautifully against the OS literature and blankly against the architecture literature reads as half-researched to half its reviewers.
The five lanes
| Lane | What must be shown | Failure the lane's reviewers spot |
|---|---|---|
| Architecture (ISCA/MICRO/HPCA lineage) | The hardware structure or mechanism is new relative to prior microarchitectural work | Reinvented prefetcher/hint/metadata scheme under a new name |
| OS/systems (SOSP/OSDI/EuroSys/ATC lineage) | The policy/runtime layer differs from existing kernel or hypervisor mechanisms | "The kernel already does this with tunables" |
| PL/compilers (PLDI/POPL/CGO lineage) | Language/compiler-level alternatives are acknowledged when the problem admits them | Hardware solution to a problem the compiler community solved statically |
| Accelerator/domain (when applicable) | Placement in the accelerator design space with honest technology normalization | Comparing against a three-generation-old design point |
| Prior ASPLOS | The intersection lineage itself — what earlier cross-layer attempts did | Missing the exact ASPLOS paper a PC member wrote or shepherded |
For the last lane, mine the venue's own memory: the ACM DL ASPLOS series and the
Influential Paper Award list (see ../../resources/exemplars/library.md) identify
the papers the community regards as canonical for a given boundary.
Differentiate on the boundary, not the components
The distinctive ASPLOS positioning move: prior work usually shares components with yours (a similar hardware structure, a similar kernel policy) while drawing the hardware/software boundary elsewhere. Say precisely where each prior system draws it and why yours moves it:
Template, per closest-prior system:
"<System> provides <capability> at <layer>, which requires <cost/assumption>.
Because it keeps <decision> in <layer>, it cannot <the thing your boundary
placement enables>. We move <decision> to <layer>, which is what makes
<headline property> possible."
Three such paragraphs beat fifteen one-line dismissals — and the systems that get this treatment should be the ones a hostile reviewer would name.
Double-blind handling of your own line of work (2027 rules)
- Cite your prior published work in the third person, treated exactly like a competitor's system.
- Your own arXiv postings and tech reports are not prior publications under the 2027 CFP, and the submission may ignore them — you are not forced into contortions differentiating against your own preprint.
- A workshop paper this submission extends, or your related manuscript under review
elsewhere, goes in as anonymized supplemental material so reviewers can judge
the delta (mechanics in
asplos-supplementary). - Never use "removed for blind review" placeholders — disallowed wording.
Format constraints that reshape this section
ASPLOS's citation rules (verified 2026-07-08) have an underappreciated interaction
with related work: every entry needs all co-authors' full first and last names
and a DOI/link, which makes each citation long. Since references are outside the
11-page limit this costs no body pages — but it means bibliography hygiene is a
real task: budget an editing pass to expand names (asplos-submission has the
mechanical sweep) rather than discovering 90 malformed entries at the deadline.
Timing and staleness
- Sweep the most recent two editions of ASPLOS, ISCA, MICRO, SOSP/OSDI, and PLDI before each gate (the September 9, 2026 deadline follows a spring conference season — its output is your reviewers' freshest context).
- Concurrent work that appears between cycles: acknowledge it neutrally in a revision or camera-ready; a Major Revision's change note is an expected place to add "since submission" positioning.
Building the lane map before writing
Construct the section from a spreadsheet, not from memory:
- For each lane, list the 5-10 systems a reviewer from that community would expect to see; source them from the last two editions' proceedings tables of contents (ACM DL for ASPLOS/ISCA/MICRO/SOSP; the respective sites for USENIX and SIGPLAN venues) rather than from citation chains, which propagate one group's blind spots.
- Mark each entry: boundary-competitor (gets a template paragraph), component-overlap (grouped sentence), or context (grouped citation).
- Have the co-author closest to each community audit their lane's list — the embarrassing omission is almost always in the lane nobody on the team calls home.
- Recheck the map at every gate: between April and September a spring conference season publishes, and a reviewer's own new paper is the citation they miss first.
Using the venue's own canon
The Influential Paper Award list is a positioning instrument, not just an
exemplar source: if your boundary has an award-validated ancestor (an
accelerator argued from data movement, a virtualization boundary redraw — see
../../resources/exemplars/library.md), citing the lineage and stating your
delta against it signals venue literacy to every senior reviewer. Conversely,
discovering that a canon paper already occupies your claimed boundary is
cheaper during this pass than in a review.
Where the section lives
With 11 figure-inclusive pages, a late monolithic related-work section is expensive real estate. The pattern that survives compression: inline differentiation at first mention for the two or three boundary-competitors (they are part of the argument, not an appendix to it), plus a compact lane-organized section that proves coverage. What must not be compressed away is the boundary-competitor analysis — cutting it saves half a page and costs the review that says "does not engage with ."
Output format
[Lane coverage] arch / OS / PL / accelerator / prior-ASPLOS — each: covered / thin / n-a
[Boundary paragraphs] closest-prior systems given the template treatment: list
[Hostile-reviewer test] the 3 systems a skeptic would name — all addressed? Y/N
[Own-work handling] third-person OK · supplements needed · arXiv stance decided
[Bibliography hygiene] full-name + DOI pass scheduled/done
[Staleness] newest cited edition per lane
Signals
- GitHub stars
- 1k
- Forks
- 146
- Last commit
- Aug 2026
Advanced
- Catalog kind
- skill
- Gateway key
asplos-related-work- Source
- github.com/brycewang-stanford/awesome-journal-skills