
Writing Systems Papers
FreeBlueprint for structuring systems conference papers.
Free · Opens the source repo
What Writing Systems Papers does
The Writing Systems Papers skill provides a detailed structural blueprint specifically designed for crafting 10-12 page systems papers intended for conferences such as OSDI, SOSP, ASPLOS, NSDI, and EuroSys. This skill outlines page allocation, paragraph templates, and writing patterns that are tailored to meet the expectations of these venues. By following the provided guidelines, authors can ensure their papers are well-organized and adhere to the specific requirements of systems research submissions.
This skill is particularly useful for researchers and practitioners in the field of computer science who are preparing to submit their work to prestigious systems conferences. It offers a clear framework for each section of the paper, from the abstract to the conclusion, ensuring that all critical elements are addressed. The skill emphasizes the importance of a structured approach, guiding users through the writing process with templates and examples that reflect best practices in the field.
In addition to the structural guidance, the skill includes specific writing patterns and rules that help authors articulate their contributions effectively. For instance, it suggests using a thesis formula to frame the paper's argument, and it emphasizes the need for thorough gap analysis and evaluation of related work. By leveraging these insights, users can enhance the clarity and impact of their writing, ultimately improving their chances of acceptance at top-tier conferences.
Overall, the Writing Systems Papers skill serves as a comprehensive resource for those looking to navigate the complexities of academic writing in the systems domain, making it an essential tool for anyone involved in this area of research.
When to use it
Use this skill when preparing a systems paper for conferences like OSDI, SOSP, ASPLOS, NSDI, or EuroSys.
When not to use it
This skill is not suitable for papers outside the systems domain or for those requiring creative writing or non-technical formats.
What you can build with it
Preparing for OSDI Submission
Use this skill to structure your paper according to OSDI guidelines, ensuring you meet the specific requirements.
Creating a Systems Paper Outline
Start with this skill to outline your systems paper, guiding you through each section's content and structure.
Enhancing Paper Clarity and Impact
Leverage the writing patterns provided to articulate your contributions clearly and effectively.
How to install Writing Systems Papers
View source1. Install with the skills CLI
npx skills add wanshuiyin/auto-claude-code-research-in-sleep/writing-systems-papers --agent claude-code2. Or install it manually
Download the skill folder and drop it into ~/.claude/skills/ for all projects, or .claude/skills/ to scope it to one repo. Restart Claude Code so it picks up the new skill.
Anthropic's agentic coding CLI, and the reference implementation of Agent Skills. Drop a skill folder into ~/.claude/skills and Claude Code loads it automatically whenever a task matches the skill's description. Claude Code docs
Inside SKILL.md
Written by wanshuiyinWriting Systems Papers: Paragraph-Level Blueprint
Structural guidance for $ARGUMENTS
Relationship to Other ARIS Skills
- paper-write: General paper generation workflow with citation verification. This skill complements it with systems-specific structural blueprints.
- paper-slides: Conference presentation generation (Beamer+PPTX). Already covers talks — no overlap.
- paper-plan: Research outline creation. Use paper-plan first, then this skill for paragraph-level structure.
Boundary: paper-write handles the generation workflow (LaTeX output, DBLP verification, section-by-section drafting). This skill provides the structural skeleton — page budgets, paragraph roles, and writing patterns specific to systems venues.
Page Allocation: 12-Page Systems Paper
| Section | Pages | Key Content |
|---|---|---|
| Abstract | ~0.25 | 150–250 words, 5 sentences |
| S1 Introduction | 1.5–2 | Problem → Gap → Insight → Contributions |
| S2 Background & Motivation | 1–1.5 | Terms + Production observations |
| S3 Design | 3–4 | Architecture + Modules + Alternatives |
| S4 Implementation | 0.5–1 | Prototype, LOC, engineering |
| S5 Evaluation | 3–4 | Setup + E2E + Ablation + Scalability |
| S6 Related Work | 1 | By methodology, explicit comparison |
| S7 Conclusion | 0.5 | 3-sentence summary |
Section Blueprints
Abstract (5 sentences)
S1: Problem context and importance
S2: Gap in existing approaches
S3: Thesis — "X is better for Y in environment Z" (Irene Zhang formula)
S4: Approach summary + headline results
S5: Impact or availability
Sources: Levin & Redell — "Can you state the new idea concisely?"; Irene Zhang — "abstract cannot use terms introduced in the paper."
S1 Introduction (1.5–2 pages)
- Problem (~0.5p) — Domain + concrete numbers + why it matters
- Gap analysis (~0.5p) — G1–Gn: specific shortcomings with evidence
- Key insight (1 para) — Thesis: "X is better for Y in Z"
- Contributions (~0.5p) — 3–5 numbered, testable claims with §N references
Pattern: hzwer Move 1 (territory) → Move 2 (niche) → Move 3 (occupy).
S2 Background & Motivation (1–1.5 pages)
- Technical background (~0.5p) — Define-before-use (Gernot Heiser)
- Observations (~0.5–1p) — O1, O2, O3 from production data → design insights
S3 Design (3–4 pages)
- Architecture overview (~0.5p) — Diagram first (Yi Ding: "draw a picture first")
- Module details (~2–2.5p) — Per module: choice, alternatives, why
- Trade-offs (~0.5–1p) — Summary of design decisions
Rule: "Every design choice must discuss alternatives" (Irene Zhang).
S4 Implementation (0.5–1 page)
Language, LOC, framework, key engineering decisions. Keep concise.
S5 Evaluation (3–4 pages)
- Setup (~0.5p) — Hardware, baselines, workloads, metrics
- End-to-end (~1–1.5p) — X vs baselines for Y on Z
- Ablation (~1–1.5p) — Remove each component, measure impact
- Scalability (~0.5p) — Behavior at increasing scale
Three-statement rule (Irene Zhang): Every conclusion stated as:
- Hypothesis (section opening)
- Conclusion (section closing)
- Caption (figure caption)
S6 Related Work (1 page)
Group by methodology. For each group: what they do, limitation, how we differ.
S7 Conclusion (0.5 page)
Three sentences: problem, solution, result. No new information.
Writing Patterns
Pattern 1: Gap Analysis
Enumerate G1–Gn in intro → A1–An in design → verify in evaluation. Example: Lucid (ASPLOS'23) — 5 gaps mapped to 5 answers.
Pattern 2: Observation-Driven
O1–O3 from production data → insights → design components. Example: GFS (arXiv 2025) — 3 observations drive 3 components.
Pattern 3: Contribution List
Numbered contributions in intro, each with §N cross-reference. Example: Blox (EuroSys'24) — 7 contributions; Sia (SOSP'23) — 5 contributions.
Pattern 4: Thesis Formula
"X is better for Y in Z" structures the entire paper. Combine with other patterns for maximum impact.
Conference Differences
Always verify against current CFP — rules change yearly.
| Venue | Format | Pages | Camera-Ready |
|---|---|---|---|
| OSDI | USENIX | 12 | 14 |
| NSDI | USENIX | 12 | 14 |
| SOSP | ACM SIGOPS | 12 | — |
| ASPLOS | ACM SIGPLAN | 11 | 13 |
| EuroSys | ACM | 12 | — |
Based on 2025/2026 CFPs.
Workflow
1. Determine venue and page limit
2. Choose writing pattern (Gap/Observation/Contribution/Thesis)
3. Allocate pages per section using the table above
4. Draft Abstract following 5-sentence template
5. Draft Introduction: Problem → Gap → Insight → Contributions
6. Draft Motivation with production observations (if available)
7. Draw architecture figure, then write Design
8. Draft Implementation (concise)
9. Draft Evaluation: setup → E2E → ablation → scalability
10. Draft Related Work by methodology groups
11. Draft Conclusion: 3 sentences
12. Run pre-submission checklist
13. Hand off to /paper-write for LaTeX generation and citation verification
Quick Self-Check
- Thesis follows "X is better for Y in Z"
- 3–5 numbered contributions with §N references
- Design discusses alternatives for every major choice
- Eval conclusions stated 3 times (hypothesis, result, caption)
- Related work grouped by methodology
- Page budget within venue limits
- No fabricated observations, traces, or results
- All citations verified (delegate to /paper-write)
Academic Integrity
- Never fabricate observations, traces, or experimental results
- Never generate citations from memory — use /paper-write citation workflow
- Disclose LLM use per venue policy
- This blueprint provides structural guidance, not copy-paste text
Authoritative Sources
- Levin & Redell — "How (and How Not) to Write a Good Systems Paper" (USENIX)
- Irene Zhang — "Hints on how to write an SOSP paper"
- Gernot Heiser — Style Guide + Paper Writing Talk
- Timothy Roscoe — "Writing reviews for systems conferences"
- Yi Ding — "How to write good systems papers?"
- hzwer & DingXiaoH — WritingAIPaper (GitHub)
Frequently asked questions about Writing Systems Papers
Similar skills
Supabase Docs Authoring
Streamline your Supabase documentation process.
Docs Writer
Streamline your documentation process with precision.
Clinical Case Report
Generate structured medical case presentations.
CrossFrame Suite
Streamline complex workflows for Chinese structural analysis.
Em Dash Expert
Master the em dash for clear, precise writing.
Nature Statistics Reporting
Enhance manuscript statistics for high-impact journal submissions.
