systems-paper-writing

Files (16)

• SKILL.md
• checklist.md · references/
• reviewer-guidelines.md · references/
• section-blueprints.md · references/
• systems-conferences.md · references/
• writing-patterns.md · references/
• main.tex · templates/asplos2027/
• references.bib · templates/asplos2027/
• main.tex · templates/nsdi2027/
• references.bib · templates/nsdi2027/
• usenix-2020-09.sty · templates/nsdi2027/
• main.tex · templates/osdi2026/
• references.bib · templates/osdi2026/
• usenix-2020-09.sty · templates/osdi2026/
• main.tex · templates/sosp2026/
• references.bib · templates/sosp2026/

SKILL.md (first lines)

# 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 page) — Enumerate specific gaps G1–Gn in existing systems. Each gap is one sentence with evidence.
3. **Key insight** (1 paragraph) — The thesis statement: "X is better for applications Y running in environment Z." (Irene Zhang formula)
4. **Contributions** (~0.5 page) — Numbered list of 3–5 concrete contributions. Each contribution is testable and maps to a section.

**Writing pattern**: hzwer Move 1 (Establish territory) → Move 2 (Find niche) → Move 3 (Occupy niche).

**Source**: Irene Zhang — "clearly state your target environment (Z) and application (Y)" + "clearly state why previous systems do not meet the needs"; Levin & Redell — "What exactly is the problem being solved?"

### S2 Background & Motivation (1–1.5 pages)

**Paragraph structure**:

1. **Technical background** (~0.5 page) — Define terms and systems the reader needs. Follow Gernot Heiser's "define-before-use" principle.
2. **Production observations** (~0.5–1 page) — Present Observation 1, 2, 3 from real data or measurements. Each observation leads to a design insight.

**Source**: Irene Zhang — "clearly motivate Y and Z. Why is application Y important?"; Gernot Heiser — "define-before-use."

### S3 Design (3–4 pages)

**Paragraph structure**:

1. **System architecture overview** (~0.5 page) — Architecture diagram first (Yi Ding: "draw a picture first"). One-paragraph walkthrough of major components and data flow.
2. **Module-by-module design** (~2–2.5 pages) — Each subsection: what the module does, the design choice made, alternatives considered, and why this choice wins.
3. **Design alternatives and trade-offs** (~0.5–1 page) — For each major decision, explicitly discuss what was not chosen and why.

**Source**: Irene Zhang — "Every design choice made in X should be discussed with alternatives and the reasons for the choice"; Levin & Redell — "What were the alternatives considered at various points, and why were the choices made?"

### S4 Implementation (0.5–1 page)

1. **Prototype description** — Language, framework, LOC, integration with existing systems.
2. **Key engineering decisions** — Non-obvious implementation choices worth documenting.

**Source**: Levin & Redell — "Does the paper describe something that has actually been implemented?"; Irene Zhang — "explain how you constructed a prototype to test your hypothesis."

### S5 Evaluation (3–4 pages)

**Paragraph structure**:

1. **Experimental setup** (~0.5 page) — Hardware, baselines, workloads, metrics. Enough detail to reproduce.
2. **End-to-end comparison** (~1–1.5 pages) — X vs baselines for application Y on environment Z. Main performance results.
3. **Microbenchmarks / Ablation** (~1–1.5 pages) — Isolate each design decision's contribution. Ablation experiments decompose the gains.
4. **Scalability** (~0.5 page) — Show behavior as problem size, cluster size, or load increases.

**Critical rule** (Irene Zhang): State every experimental conclusion **three times**:
- Section opening: hypothesis ("We expect X to outperform Y because...")
- Section closing: conclusion ("Results show X outperforms Y by Z%")
- Figure caption: evidence ("Figure N shows X achieves Z% better throughput than Y")

**Two experiment types**:
- Type 1: X vs baselines for Y on Z (end-to-end comparison)

From Orchestra-Research/AI-Research-SKILLs, MIT.

More from Orchestra-Research/AI-Research-SKILLs