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.
89%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
Passed
No findings from the security scan
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.
| 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.
This blueprint synthesizes guidance from established systems researchers:
Full citations and URLs: see references/section-blueprints.md.
| 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. |
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 availabilitySource: 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."
Paragraph structure:
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?"
Paragraph structure:
Source: Irene Zhang — "clearly motivate Y and Z. Why is application Y important?"; Gernot Heiser — "define-before-use."
Paragraph structure:
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?"
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."
Paragraph structure:
Critical rule (Irene Zhang): State every experimental conclusion three times:
Two experiment types:
Source: Levin & Redell — "Are comparisons with previous work clear and explicit?"; Irene Zhang — use comparison tables.
Three sentences (Irene Zhang formula):
Four reusable patterns for structuring systems papers. See references/writing-patterns.md for detailed examples.
Enumerate gaps G1–Gn in Introduction → map to answers A1–An in Design. Creates a clear contract with the reader.
Present production observations (O1–O3) in Motivation → derive design insights → build system around insights. Effective when you have real workload data.
Numbered contributions in Introduction, each mapping to a section. Readers (and reviewers) can track claims through the paper.
Structure the entire paper around: "X is better for applications Y running in environment Z." Introduction states it, Design explains how, Evaluation proves it.
Warning: Venue rules change yearly. Always verify against the current year's CFP before submission.
| Venue | Format | Submission Limit | Camera-Ready | References |
|---|---|---|---|---|
| OSDI | USENIX | 12 pages | 14 pages | Unlimited |
| NSDI | USENIX | 12 pages | 14 pages | Unlimited |
| SOSP | ACM SIGOPS | 12 pages (tech content) | — | Unlimited |
| ASPLOS | ACM SIGPLAN | 11 pages | 13 pages | Unlimited |
| EuroSys | ACM | 12 pages | — | Unlimited |
Based on 2025/2026 CFPs. Verify current limits before submission.
Treat the reader's cognitive load like an OS managing process state. Never introduce a concept without context. Never reference something defined later without a forward pointer.
Self-check against: Original Ideas, Reality (is it built?), Lessons (what did you learn?), Choices (alternatives discussed?), Context (related work fair?), Presentation (clear writing?).
Include a figure on the first page that captures the core idea. Reviewers form first impressions from the title, abstract, and page-one figure.
[CITATION NEEDED].Step 1: Read this SKILL.md for page allocation overview
Step 2: Read references/section-blueprints.md for per-section paragraph templates
Step 3: Choose a writing pattern from references/writing-patterns.md
Step 4: Draft section by section following the blueprint
Step 5: Run the checklist from references/checklist.md before submission
Step 6: Use ml-paper-writing for citation verification and LaTeX formatting| Issue | Solution |
|---|---|
| Paper feels like a "feature list" | Restructure around thesis formula: X better for Y in Z |
| Evaluation lacks depth | Add ablation experiments isolating each design decision |
| Reviewers say "incremental" | Strengthen gap analysis: make G1–Gn crisper with evidence |
| Design section too long | Move implementation details to S4, keep S3 at design level |
| Motivation feels weak | Add production observations with concrete numbers |
| Related work reads like a bibliography | Group by approach, add explicit differentiation |
Orchestra-Research/AI-Research-SKILLs
773a529
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.