Skill detail
systems-paper-writing
Direct systems research-paper writing guidance.
Inspect before use
Automated review checks relevance, not safety or endorsement. Read the source instructions before using this skill.
SKILL.md
The saved excerpt is a snapshot from review. The external source remains the complete and most current version.
---
name: systems-paper-writing
description: Comprehensive guide for writing systems papers targeting OSDI, SOSP, ASPLOS, NSDI, and EuroSys. Provides paragraph-level structural blueprints, writing patterns, venue-specific checklists, reviewer guidelines, LaTeX templates, and conference deadlines. Use this skill for all systems conference paper writing.
version: 1.1.0
author: Orchestra Research
license: MIT
tags: [Systems Paper Writing, OSDI, SOSP, ASPLOS, NSDI, EuroSys, Structural Blueprint, Academic Writing, LaTeX]
---
# Systems Paper Writing: Paragraph-Level Structural Blueprint
Fine-grained structural guidance for writing **10–12 page systems papers** targeting top systems venues: OSDI, SOSP, ASPLOS, NSDI, and EuroSys. This skill provides page allocation per section, paragraph-level blueprints, and writing patterns distilled from authoritative guides and best-paper analysis.
## When to Use This Skill
| Scenario | Use This Skill | Use ml-paper-writing Instead |
|----------|---------------|------------------------------|
| Structuring a 12-page OSDI/SOSP paper | ✅ | |
| Page budget and paragraph planning | ✅ | |
| Systems-specific evaluation structure | ✅ | |
| General ML paper writing philosophy | | ✅ |
| Citation verification workflow | | ✅ |
| LaTeX templates and formatting | | ✅ |
| NeurIPS/ICML/ICLR paper structure | | ✅ |
**Boundary**: ml-paper-writing provides general writing philosophy, multi-venue templates, and citation verification. This skill focuses exclusively on **paragraph-level structural blueprints** for systems conferences.
---
## Authoritative Sources
This blueprint synthesizes guidance from established systems researchers:
1. **Levin & Redell** — "How (and How Not) to Write a Good Systems Paper" (SOSP'83 PC Chairs, USENIX/ACM SIGOPS)
2. **Irene Zhang** (MSR/UW) — "Hints on how to write an SOSP paper" (SOSP/OSDI PC)
3. **Gernot Heiser** (UNSW, seL4) — Style Guide + Paper Writing Talk
4. **Timothy Roscoe** (ETH Zürich) — "Writing reviews for systems conferences"
5. **Mike Dahlin** (UT Austin/Google) — "Giving a Conference Talk"
6. **Yi Ding** — "How to write good systems papers?"
7. **hzwer & DingXiaoH** — WritingAIPaper (GitHub 1.3k+ stars)
Full citations and URLs: see [references/section-blueprints.md](references/section-blueprints.md).
---
## 12-Page Systems Paper Blueprint
### Overview: Page Allocation
| Section | Pages | Purpose |
|---------|-------|---------|
| Abstract | ~0.25 | 150–250 words, 5-sentence structure |
| S1 Introduction | 1.5–2 | Problem → Gap → Insight → Contributions |
| S2 Background & Motivation | 1–1.5 | Terms + Production observations |
| S3 Design | 3–4 | Architecture + Module details + Alternatives |
| S4 Implementation | 0.5–1 | Prototype details, LOC, key engineering |
| S5 Evaluation | 3–4 | Setup + End-to-end + Microbenchmarks + Scalability |
| S6 Related Work | 1 | Grouped by methodology, explicit comparison |
| S7 Conclusion | 0.5 | 3-sentence summary |
| **Total** | **~12** | Submission: 12 pages strict (USENIX) / 11 pages (ACM ASPLOS). Camera-ready: up to 14 pages (USENIX) / 13 pages (ACM). Ranges above span submission through camera-ready. Target 12 pages for initial submission. References unlimited. |
### Abstract (150–250 words, 5 sentences)
```text
Sentence 1: Problem context and importance
Sentence 2: Gap in existing approaches
Sentence 3: Key insight or thesis ("X is better for Y in environment Z")
Sentence 4: Summary of approach and key results
Sentence 5: Broader impact or availability
```
**Source**: Levin & Redell — "Can you state the new idea concisely? Use them in the abstract." Irene Zhang — "The abstract is harder to write because you cannot use terms or concepts you introduced in the paper."
### S1 Introduction (1.5–2 pages)
**Paragraph structure**:
1. **Problem statement** (~0.5 page) — Establish the domain and why it matters. Use concrete numbers (cluster sizes, workload statistics, latency requirements).
2. **Gap analysis** (~0.5 pagRead the full source on GitHub (opens external page)