/atc-related-work
Use when writing or auditing the related-work and positioning of an ATC (ACM SIGOPS Annual Technical Conference, formerly USENIX ATC) systems paper — covering the systems literature lanes, positioning against OSDI/SOSP/NSDI/EuroSys/FAST, writing delta-first comparisons, and
$ npx -y skills add brycewang-stanford/Awesome-Journal-Skills --skill atc-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
/atc-related-work
Context preview
The summary Claude sees to decide when to auto-load this skill.
Use when writing or auditing the related-work and positioning of an ATC (ACM SIGOPS Annual Technical Conference, formerly USENIX ATC) systems paper — covering the systems literature lanes, positioning against OSDI/SOSP/NSDI/EuroSys/FAST, writing delta-first comparisons, and
SKILL.md
atc-related-work.SKILL.mdname: atc-related-work
description: Use when writing or auditing the related-work and positioning of an ATC (ACM SIGOPS Annual Technical Conference, formerly USENIX ATC) systems paper — covering the systems literature lanes, positioning against OSDI/SOSP/NSDI/EuroSys/FAST, writing delta-first comparisons, and keeping self-citation double-blind.
ATC Related Work
Position the paper in the systems literature, not against a strawman. ATC's broad scope means your reviewers span subareas, and a related-work section that a storage reviewer and a networking reviewer both find fair is a signal the paper is well situated. Because review is **double-blind**, positioning and self-citation must be handled carefully.
Cover the lanes a systems reviewer expects
For most ATC papers, at least these lanes should be visible:
- **The direct predecessors** — the systems and techniques you build on or replace, with the
specific mechanism you change.
- **The alternative approaches** — other ways the community has attacked this problem, and why yours
differs (not just "we are better," but *how* the design differs and what that buys).
- **The adjacent subareas** — where an idea from storage, networking, virtualization, or scheduling
informs your design; ATC reviewers respect cross-pollination when it is credited.
- **The measurement/experience literature** — prior studies of the phenomenon you address, so your
motivation rests on evidence, not assertion.
Delta-first positioning
Write each comparison **delta-first**: state what the prior system does, then the *specific* difference and its consequence.
- Weak: "Unlike X, our system is more efficient."
- Strong: "X admits objects on first reference, spending write budget before reuse is known; our
policy defers admission to a probation window, so writes concentrate on reused objects — the difference we measure in §4."
A delta a reviewer can check against your evaluation is worth more than a paragraph of adjectives. Every claimed delta should map to an experiment (see `atc-experiments`).
Sibling-venue awareness
ATC sits among specialized and flagship systems venues, and reviewers will expect you to engage the right literature regardless of where it appeared:
- **OSDI / SOSP:** the flagship line for your subarea — cite the landmark systems even though ATC is
broader; ignoring them reads as unfamiliarity.
- **NSDI:** for anything touching the network stack, dataplanes, or protocols.
- **FAST:** for storage and file-system work.
- **EuroSys:** the other broad SIGOPS-family systems venue — closely related programs.
- **Workshops (HotOS/HotStorage):** where the idea may have first appeared as a position.
Do not misattribute a landmark to ATC because it is famous — many canonical systems papers are OSDI/SOSP/NSDI (see `resources/exemplars/library.md` for the guardrail list). Cite each to its real venue.
Double-blind self-citation
- Cite your own prior systems and papers **in the third person** — "System X [12] admits on first
reference" — never "our prior system."
- Do **not** write "reference removed for blind review"; keep the citation, anonymized in phrasing.
- Watch for **implicit** de-anonymization: an unusual system name, a niche testbed, or a dataset only
your group has can identify you as surely as a name. Neutralize the phrasing or note it generically.
- If a comparison genuinely requires your non-anonymous artifact, mirror it behind a blind service
(see `atc-submission`).
Common failure modes
- **Adjacent-work blind spot** — missing a sibling-venue line a subarea reviewer will know cold.
- **Comparison without a measurable delta** — claims of superiority not tied to an experiment.
- **Strawman baselines in prose** — describing prior work as weaker than it is; reviewers who know
it will distrust the rest.
- **Self-citation leak** — first-person references or an identifying system name breaking anonymity.
- **Venue misattribution** — crediting a flagship result to ATC (or vice versa).
Output format
[Lane coverage] predecessors / alternatives / adjacent subareas / measurement literature: gaps?
[Delta check] each key comparison stated delta-first and mapped to an experiment? yes/no
[Sibling-venue] OSDI/SOSP/NSDI/EuroSys/FAST lines engaged where relevant? misattributions?
[Anonymity] self-citations third-person? identifying names/testbeds neutralized? "removed for review" absent?
[Fix queue] <ordered edits, most reviewer-visible first>
Read more
name: atc-related-work description: Use when writing or auditing the related-work and positioning of an ATC (ACM SIGOPS Annual Technical Conference, formerly USENIX ATC) systems paper — covering the systems literature lanes, positioning against OSDI/SOSP/NSDI/EuroSys/FAST, writing delta-first comparisons, and keeping self-citation double-blind.
ATC Related Work
Position the paper in the systems literature, not against a strawman. ATC's broad scope means your reviewers span subareas, and a related-work section that a storage reviewer and a networking reviewer both find fair is a signal the paper is well situated. Because review is **double-blind**, positioning and self-citation must be handled carefully.
Cover the lanes a systems reviewer expects
For most ATC papers, at least these lanes should be visible:
- **The direct predecessors** — the systems and techniques you build on or replace, with the
specific mechanism you change.
- **The alternative approaches** — other ways the community has attacked this problem, and why yours
differs (not just "we are better," but *how* the design differs and what that buys).
- **The adjacent subareas** — where an idea from storage, networking, virtualization, or scheduling
informs your design; ATC reviewers respect cross-pollination when it is credited.
- **The measurement/experience literature** — prior studies of the phenomenon you address, so your
motivation rests on evidence, not assertion.
Delta-first positioning
Write each comparison **delta-first**: state what the prior system does, then the *specific* difference and its consequence.
- Weak: "Unlike X, our system is more efficient."
- Strong: "X admits objects on first reference, spending write budget before reuse is known; our
policy defers admission to a probation window, so writes concentrate on reused objects — the difference we measure in §4."
A delta a reviewer can check against your evaluation is worth more than a paragraph of adjectives. Every claimed delta should map to an experiment (see `atc-experiments`).
Sibling-venue awareness
ATC sits among specialized and flagship systems venues, and reviewers will expect you to engage the right literature regardless of where it appeared:
- **OSDI / SOSP:** the flagship line for your subarea — cite the landmark systems even though ATC is
broader; ignoring them reads as unfamiliarity.
- **NSDI:** for anything touching the network stack, dataplanes, or protocols.
- **FAST:** for storage and file-system work.
- **EuroSys:** the other broad SIGOPS-family systems venue — closely related programs.
- **Workshops (HotOS/HotStorage):** where the idea may have first appeared as a position.
Do not misattribute a landmark to ATC because it is famous — many canonical systems papers are OSDI/SOSP/NSDI (see `resources/exemplars/library.md` for the guardrail list). Cite each to its real venue.
Double-blind self-citation
- Cite your own prior systems and papers **in the third person** — "System X [12] admits on first
reference" — never "our prior system."
- Do **not** write "reference removed for blind review"; keep the citation, anonymized in phrasing.
- Watch for **implicit** de-anonymization: an unusual system name, a niche testbed, or a dataset only
your group has can identify you as surely as a name. Neutralize the phrasing or note it generically.
- If a comparison genuinely requires your non-anonymous artifact, mirror it behind a blind service
(see `atc-submission`).
Common failure modes
- **Adjacent-work blind spot** — missing a sibling-venue line a subarea reviewer will know cold.
- **Comparison without a measurable delta** — claims of superiority not tied to an experiment.
- **Strawman baselines in prose** — describing prior work as weaker than it is; reviewers who know
it will distrust the rest.
- **Self-citation leak** — first-person references or an identifying system name breaking anonymity.
- **Venue misattribution** — crediting a flagship result to ATC (or vice versa).
Output format
[Lane coverage] predecessors / alternatives / adjacent subareas / measurement literature: gaps? [Delta check] each key comparison stated delta-first and mapped to an experiment? yes/no [Sibling-venue] OSDI/SOSP/NSDI/EuroSys/FAST lines engaged where relevant? misattributions? [Anonymity] self-citations third-person? identifying names/testbeds neutralized? "removed for review" absent? [Fix queue] <ordered edits, most reviewer-visible first>
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

