@r1z4x/tezgah 1.0.0

package/skills/ai-research/20-ml-paper-writing/systems-paper-writing/SKILL.md

@@ -0,0 +1,270 @@
+---
+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 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)
+- Type 2: Ablation — remove each design component to measure its individual impact
+
+### S6 Related Work (1 page)
+
+- Group by **methodology or approach**, not by individual papers.
+- For each group: what they do, what limitation remains, how your work differs.
+- Use a comparison table when comparing 4+ systems on specific dimensions.
+
+**Source**: Levin & Redell — "Are comparisons with previous work clear and explicit?"; Irene Zhang — use comparison tables.
+
+### S7 Conclusion (0.5 page)
+
+Three sentences (Irene Zhang formula):
+1. The hypothesis / problem addressed
+2. The solution approach
+3. The key result
+
+---
+
+## Writing Patterns
+
+Four reusable patterns for structuring systems papers. See [references/writing-patterns.md](references/writing-patterns.md) for detailed examples.
+
+### Pattern 1: Gap Analysis (Lucid, ASPLOS'23)
+Enumerate gaps G1–Gn in Introduction → map to answers A1–An in Design. Creates a clear contract with the reader.
+
+### Pattern 2: Observation-Driven (GFS, arXiv 2025)
+Present production observations (O1–O3) in Motivation → derive design insights → build system around insights. Effective when you have real workload data.
+
+### Pattern 3: Contribution List (Blox, EuroSys'24; Sia, SOSP'23)
+Numbered contributions in Introduction, each mapping to a section. Readers (and reviewers) can track claims through the paper.
+
+### Pattern 4: Thesis Formula (Irene Zhang)
+Structure the entire paper around: "X is better for applications Y running in environment Z." Introduction states it, Design explains how, Evaluation proves it.
+
+---
+
+## Conference Differences
+
+> **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.
+
+---
+
+## Writing Philosophy
+
+### Manage Reader State (Gernot Heiser)
+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.
+
+### Six-Dimensional Quality (Levin & Redell)
+Self-check against: **Original Ideas**, **Reality** (is it built?), **Lessons** (what did you learn?), **Choices** (alternatives discussed?), **Context** (related work fair?), **Presentation** (clear writing?).
+
+### Page-One Figure (hzwer)
+Include a figure on the first page that captures the core idea. Reviewers form first impressions from the title, abstract, and page-one figure.
+
+---
+
+## Academic Integrity Requirements
+
+### Citation Discipline
+- **Never generate citations from memory.** Use ml-paper-writing's citation verification workflow (Semantic Scholar / DBLP / CrossRef APIs).
+- Mark unverified references as `[CITATION NEEDED]`.
+
+### Prohibition of Fabrication
+- Do NOT fabricate production observations, traces, deployment experiences, or experimental results.
+- Do NOT generate fake venue rules, paper metadata, or best-paper claims.
+- Do NOT copy paragraph-level text from reference papers. This blueprint provides **structural guidance**, not copy-paste templates.
+
+### LLM Disclosure
+- Some venues require disclosure of substantial LLM use in writing or ideation. Check each venue's AI policy in the current CFP.
+
+### Attribution
+- When structures are inspired by specific papers (e.g., Lucid's gap-analysis pattern), cite the inspiration.
+- Cross-repository references (e.g., ARIS paper-slides structure) are attributed, not copied.
+
+### Temporal Validity
+- Venue rules (page limits, format, AI policies) change annually. All venue information in this skill is based on 2025/2026 CFPs. **Always verify against the current year's CFP.**
+
+---
+
+## Workflow: Structuring a New Systems Paper
+
+```text
+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
+```
+
+### Quick Checklist
+
+- [ ] Thesis statement follows "X is better for Y in Z" formula
+- [ ] Introduction has numbered contributions (3–5)
+- [ ] Each contribution maps to a paper section
+- [ ] Design discusses alternatives for every major choice
+- [ ] Every eval conclusion stated 3 times (hypothesis, result, caption)
+- [ ] Related work grouped by methodology, not individual papers
+- [ ] Page budget within venue limits
+- [ ] All citations verified programmatically (no hallucinated references)
+
+---
+
+## Common Issues and Solutions
+
+| 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 |
+
+---
+
+## References
+
+### Writing Guidance
+- [references/section-blueprints.md](references/section-blueprints.md) — Detailed per-section paragraph templates with authoritative source quotes and best-paper structural examples
+- [references/writing-patterns.md](references/writing-patterns.md) — Four writing patterns with concrete paper examples
+
+### Venue-Specific
+- [references/checklist.md](references/checklist.md) — 7-stage pre-submission checklist covering structure, writing quality, evaluation rigor, design quality, academic integrity, venue-specific requirements (OSDI/NSDI/ASPLOS/SOSP/EuroSys), and final pass
+- [references/systems-conferences.md](references/systems-conferences.md) — Conference overview, deadlines, track descriptions, formatting requirements, submission rules, and format conversion guides
+- [references/reviewer-guidelines.md](references/reviewer-guidelines.md) — How systems conference reviewers evaluate papers, with venue-specific criteria and common concerns
+
+### LaTeX Templates
+- [templates/osdi2026/](templates/osdi2026/) — OSDI 2026 (USENIX format)
+- [templates/nsdi2027/](templates/nsdi2027/) — NSDI 2027 (USENIX format)
+- [templates/asplos2027/](templates/asplos2027/) — ASPLOS 2027 (ACM SIGPLAN format)
+- [templates/sosp2026/](templates/sosp2026/) — SOSP 2026 (ACM SIGPLAN format)

package/skills/ai-research/20-ml-paper-writing/systems-paper-writing/references/checklist.md

@@ -0,0 +1,279 @@
+<!-- vendored from orchestra-research/AI-research-SKILLs@773a52944ba4747a18bd4ae9ade53fff041adcbc 20-ml-paper-writing/systems-paper-writing/references/checklist.md; MIT (c) Orchestra Research -->
+# Pre-Submission Checklist for Systems Papers
+
+Comprehensive self-check before submitting to OSDI, SOSP, ASPLOS, NSDI, and EuroSys. Combines community best practices (MLNLP-World/Paper-Writing-Tips, RU-System/Paper_Writing_Tips) with systems-specific and academic integrity checks.
+
+---
+
+## Stage 1: Structural Completeness
+
+### Thesis & Contributions
+- [ ] Paper has a clear thesis statement: "X is better for Y in Z"
+- [ ] Thesis appears in Abstract (sentence 3), Introduction, and Conclusion
+- [ ] Introduction lists 3–5 numbered, testable contributions
+- [ ] Each contribution cross-references a paper section (§N)
+- [ ] Each contribution is verified by an experiment in §5
+
+### Section Presence
+- [ ] Abstract: 150–250 words, self-contained (no undefined terms)
+- [ ] Introduction: Problem → Gap → Insight → Contributions
+- [ ] Background/Motivation: Technical terms defined before use
+- [ ] Design: Architecture figure + module details + alternatives
+- [ ] Implementation: Language, LOC, framework, key decisions
+- [ ] Evaluation: Setup + end-to-end + ablation + scalability
+- [ ] Related Work: Grouped by approach, explicit differentiation
+- [ ] Conclusion: 3-sentence summary (problem, solution, result)
+
+### Page Budget
+- [ ] Total pages within venue limit (see venue table below)
+- [ ] Design section: 3–4 pages (not overlong)
+- [ ] Evaluation section: 3–4 pages (not underweight)
+- [ ] Related Work: ~1 page (not a bibliography dump)
+- [ ] Implementation: 0.5–1 page (concise)
+
+---
+
+## Stage 2: Writing Quality
+
+### Clarity (Gernot Heiser)
+- [ ] No forward references without explicit pointers ("as we show in §N")
+- [ ] Every acronym defined on first use
+- [ ] No orphan terminology — every technical term defined before use
+- [ ] Consistent naming: system name capitalized uniformly throughout
+- [ ] Active voice preferred over passive where possible
+
+### Figures & Tables (MLNLP-World/Paper-Writing-Tips)
+- [ ] Every figure/table referenced in text before it appears
+- [ ] Figure captions are self-contained (readable without text)
+- [ ] Evaluation figure captions include the key finding
+- [ ] Architecture figure appears within first 3 pages
+- [ ] Fonts in figures ≥ 8pt (readable when printed)
+- [ ] Colors distinguishable in grayscale (for B&W printing)
+- [ ] Consistent plot styles across all evaluation figures
+
+### LaTeX Quality
+- [ ] All code blocks have language tags (```python, ```bash, etc.)
+- [ ] Non-breaking spaces before references: `Section~\ref{...}`
+- [ ] Consistent citation format: `\cite{...}` not mixed with `[N]`
+- [ ] No overfull hbox warnings in LaTeX log
+- [ ] Bibliography entries have complete metadata (authors, title, venue, year)
+
+### Prose Quality (RU-System/Paper_Writing_Tips)
+- [ ] No hedging without evidence ("we believe", "it seems")
+- [ ] Quantitative claims have numbers ("significantly better" → "37% better")
+- [ ] No first-person unless venue style requires it
+- [ ] Contributions are specific, not vague ("novel" without explanation)
+- [ ] Related work comparisons are fair and accurate
+
+---
+
+## Stage 3: Evaluation Rigor
+
+### Experimental Methodology
+- [ ] Baselines are state-of-the-art (not straw men)
+- [ ] Baselines configured optimally (not default/untuned)
+- [ ] Hardware, software versions, and configurations fully specified
+- [ ] Workloads described in sufficient detail to reproduce
+- [ ] Statistical significance: error bars, multiple runs, or confidence intervals
+- [ ] Warmup runs excluded from measurements
+
+### Result Presentation
+- [ ] Every conclusion stated 3 times: hypothesis (§ opening), result (§ closing), caption (figure)
+- [ ] Ablation study isolates each design component
+- [ ] Scalability experiments show behavior at increasing scale
+- [ ] Both favorable and unfavorable results discussed honestly
+- [ ] Performance numbers are absolute (not only relative percentages)
+
+### Reproducibility
+- [ ] Source code availability stated (or planned)
+- [ ] Key hyperparameters and configuration values listed
+- [ ] Workload generation described or traces cited
+- [ ] Enough detail for an independent team to reproduce within ~2 weeks
+
+---
+
+## Stage 4: Design Quality
+
+### Alternatives Discussion (Irene Zhang)
+- [ ] Every major design decision discusses at least one alternative
+- [ ] Alternatives are genuinely considered (not straw men)
+- [ ] Trade-offs for each alternative explicitly stated
+- [ ] Reasons for rejection are technical (not "it was harder to implement")
+
+### Correctness Arguments
+- [ ] System handles failure cases (discussed or evaluated)
+- [ ] Edge cases acknowledged (even if not fully solved)
+- [ ] Threat model or assumptions section present (if applicable)
+- [ ] Limitations stated honestly (not hidden)
+
+---
+
+## Stage 5: Academic Integrity
+
+### Citation Discipline
+- [ ] **Every citation verified programmatically** (Semantic Scholar / DBLP / CrossRef)
+- [ ] No citations generated from memory or LLM output
+- [ ] Unverified citations marked as `[CITATION NEEDED]`
+- [ ] All BibTeX entries have: authors, title, venue, year, pages/DOI
+- [ ] No fabricated paper titles, authors, or venues
+- [ ] Self-citations are relevant (not padding)
+
+### Data Integrity
+- [ ] Production observations are from real data (not fabricated)
+- [ ] Experimental results are from actual runs (not interpolated/extrapolated)
+- [ ] Traces cited with source (public dataset or anonymized description)
+- [ ] No results cherry-picked without disclosing selection criteria
+
+### LLM Disclosure
+- [ ] Check venue's AI/LLM use policy in current CFP
+- [ ] If LLM used for substantial writing: disclose as required
+- [ ] If LLM used for code generation: disclose as required
+- [ ] Confirm all LLM-assisted content reviewed by human authors
+
+### Originality
+- [ ] No paragraph-level text copied from other papers
+- [ ] Structural patterns inspired by other papers are attributed
+- [ ] Cross-repository content (if any) is attributed, not copied
+- [ ] Related work descriptions are original paraphrases, not copy-paste
+
+---
+
+## Stage 6: Venue-Specific Requirements
+
+> **Verify against the current year's CFP** — rules change annually.
+
+### All Systems Venues
+
+- [ ] **System design and implementation** — not just algorithms
+- [ ] **Real workloads and evaluation** — microbenchmarks are insufficient
+- [ ] **Practical benefits demonstrated** — latency, throughput, cost, energy
+- [ ] **Comparison with state-of-the-art systems**
+- [ ] **No simultaneous submission to other venues**
+- [ ] **Prior arXiv/tech reports permitted**
+
+### Page Limits Quick Reference
+
+| Conference | Main Content | Camera-Ready | References | Format |
+|------------|-------------|--------------|------------|--------|
+| OSDI 2026 | 12 pages | 14 pages | Unlimited | USENIX |
+| NSDI 2027 | 12 pages | varies | Unlimited | USENIX |
+| ASPLOS 2027 | 12 pages | varies | Unlimited | ACM SIGPLAN |
+| SOSP 2026 | 12 pages | varies | Unlimited | ACM SIGPLAN |
+| EuroSys | 12 pages | varies | Unlimited | ACM |
+
+### OSDI 2026
+
+OSDI focuses on innovative research and quantified/insightful experiences in systems design and implementation.
+
+**Tracks:**
+- **Research Track**: Novel systems research
+- **Operational Systems Track** (New in 2026): Design, implementation, analysis, and experience of operational systems
+
+**Checklist:**
+- [ ] ≤12 pages (excluding references)
+- [ ] 8.5" x 11" pages, 10pt on 12pt leading, two-column, Times Roman
+- [ ] 7" wide x 9" deep text block
+- [ ] Pages are numbered
+- [ ] Figures and tables legible in black and white
+- [ ] Paper is the right length (not padded; <6pp unlikely to receive full consideration)
+- [ ] Double-blind: no author names, affiliations
+- [ ] Anonymized project/system name (different from arXiv/talks)
+- [ ] Track indicated on title page and submission form
+- [ ] Operational Systems papers: title ends with "(Operational Systems)"
+- [ ] Max 8 submissions per author
+- [ ] Work NOT wholly or largely generated by AI (AI editing tools are acceptable)
+
+### NSDI 2027
+
+NSDI focuses on design principles, implementation, and practical evaluation of networked and distributed systems.
+
+**Tracks:**
+- **Traditional Research Track**: Novel ideas with thorough evaluations
+- **Frontiers Track** (New): Bold ideas without necessarily complete evaluation
+- **Operational Systems Track**: Deployed systems with lessons learned
+
+**Prescreening:** Reviewers read only the Introduction to check:
+- [ ] Subject falls within NSDI scope
+- [ ] Exposition understandable by NSDI PC member
+- [ ] Track-specific criteria articulated in Introduction
+
+**Checklist:**
+- [ ] ≤12 pages (excluding references), USENIX format
+- [ ] Two-column, 10pt, Times Roman
+- [ ] Double-blind anonymized
+- [ ] Contributions to networked systems design
+- [ ] NOT out-of-scope topics (hardware architecture, physical layer, sensing, UI)
+- [ ] Track indicated on title page and submission form
+- [ ] Not rejected from previous NSDI deadline without one-shot revision option
+
+### ASPLOS 2027
+
+ASPLOS focuses on the intersection of computer architecture, programming languages, and operating systems.
+
+**Rapid Review Round** (unique to ASPLOS):
+- Reviewers only read the **first 2 pages**
+- Evaluates how work advances Architecture/PL/OS research
+- Majority of submissions may not advance past this stage
+
+**Checklist:**
+- [ ] First 2 pages self-contained: clearly states problem, approach, and contribution
+- [ ] Advances Architecture, PL, and/or OS research
+- [ ] Not just advances in another domain using arch/PL/OS
+- [ ] ACM SIGPLAN format (`\documentclass[sigplan,10pt]{acmart}`)
+- [ ] ≤12 pages (excluding references)
+- [ ] Double-blind anonymized
+- [ ] Max 4 submissions per author per cycle
+- [ ] Resubmission note describing changes (if applicable)
+- [ ] Not resubmitted from immediate previous ASPLOS cycle
+
+### SOSP 2026
+
+SOSP seeks innovative research related to design, implementation, analysis, evaluation, and deployment of computer systems software.
+
+**Checklist:**
+- [ ] ACM SIGPLAN format (`\documentclass[sigplan,10pt]{acmart}`)
+- [ ] ≤12 pages technical content (excluding references)
+- [ ] A4 or US letter, 178×229mm (7×9") text block
+- [ ] Two-column, 8mm separation, 10pt on 12pt leading
+- [ ] Pages numbered, references hyperlinked
+- [ ] Figures/tables readable without magnification, encouraged in color but grayscale-readable
+- [ ] Double-blind: paper ID instead of author names
+- [ ] Anonymized system/project name
+- [ ] Own work cited in third person
+- [ ] No acknowledgments or grant numbers
+- [ ] Artifact evaluation materials prepared (optional but recommended)
+- [ ] Author response ≤500 words, no new experiments
+
+### EuroSys
+
+- [ ] ACM template used
+- [ ] Page limit: 12 pages
+- [ ] Double-blind formatting
+- [ ] Artifact evaluation encouraged
+
+---
+
+## Stage 7: Final Pass
+
+### Before Clicking Submit
+- [ ] PDF renders correctly (no missing fonts, broken figures)
+- [ ] All TODO/FIXME comments removed from source
+- [ ] `[CITATION NEEDED]` markers resolved or removed
+- [ ] Author names correct (camera-ready) or removed (blind)
+- [ ] Acknowledgements removed for blind submission
+- [ ] Supplementary material properly anonymized
+- [ ] File size within submission system limits
+- [ ] Paper title matches submission system entry
+- [ ] Abstract in submission system matches paper abstract
+- [ ] Correct track/topic area selected in submission system
+
+### One-Sentence Self-Test (Levin & Redell Six Dimensions)
+For each dimension, answer in one sentence:
+1. **Original Ideas**: What is genuinely new?
+2. **Reality**: Is the system built and tested?
+3. **Lessons**: What did we learn that others can use?
+4. **Choices**: Did we discuss alternatives for every major decision?
+5. **Context**: Is the related work fair and complete?
+6. **Presentation**: Would a non-expert in this subfield understand the paper?
+
+If any answer is weak, revise that aspect before submitting.

package/skills/ai-research/20-ml-paper-writing/systems-paper-writing/references/reviewer-guidelines.md

@@ -0,0 +1,116 @@
+<!-- vendored from orchestra-research/AI-research-SKILLs@773a52944ba4747a18bd4ae9ade53fff041adcbc 20-ml-paper-writing/systems-paper-writing/references/reviewer-guidelines.md; MIT (c) Orchestra Research -->
+# Systems Conference Reviewer Guidelines
+
+Systems conferences (OSDI, NSDI, ASPLOS, SOSP) evaluate papers differently from ML/AI venues. Understanding these differences is critical for cross-venue submissions.
+
+---
+
+## Core Evaluation Criteria for Systems
+
+| Criterion | What Reviewers Look For |
+|-----------|------------------------|
+| **Novelty** | New system design, not just incremental improvement |
+| **Significance** | Solves important practical problem |
+| **System Design** | Sound architecture, clear design decisions |
+| **Implementation** | Working prototype, not just simulation |
+| **Evaluation** | Real workloads, end-to-end performance |
+| **Clarity** | Clear writing, reproducible |
+
+## OSDI 2026 Reviewer Perspective
+
+**What reviewers evaluate:**
+- Topic relevance to computer systems
+- Potential to impact future systems research and practices
+- Interest to substantial portion of OSDI attendees
+- Papers with little PC overlap are less likely accepted
+
+**Research Track criteria:**
+- Novelty, significance, clarity, relevance, correctness
+- Quantified or insightful experiences in systems
+
+**Operational Systems Track criteria:**
+- Real-world deployment at meaningful scale
+- Lessons that deepen understanding of existing problems
+- Disproves or strengthens existing assumptions
+- Novel research ideas NOT required
+
+**New in 2026:**
+- No author response period
+- Conditional accept replaces revise-and-resubmit
+- Target acceptance rate ≥20%
+- Reviewers encouraged to down-rank padded papers
+
+## NSDI 2027 Reviewer Perspective
+
+**Prescreening (Introduction only):**
+
+Reviewers check three criteria in the prescreening phase:
+1. **Scope**: Subject within NSDI topics
+2. **Accessibility**: Understandable by PC member
+3. **Track alignment**: Meets track-specific criteria
+
+**Track-specific review:**
+
+| Track | Key Criterion |
+|-------|---------------|
+| Research | Novel idea + compelling evaluation evidence |
+| Frontiers | Bold non-incremental idea (complete evaluation not required) |
+| Operational | Deployment context, scale, lessons for community |
+
+**One-shot revision:**
+- Rejected papers may receive a list of issues to address
+- Authors can resubmit revision at next deadline
+- Same reviewers review the revision (to extent possible)
+
+## ASPLOS 2027 Reviewer Perspective
+
+**Rapid Review Round:**
+- Reviewers read ONLY first 2 pages
+- Evaluates: Does this advance Architecture, PL, or OS research?
+- Majority of submissions may not advance past this stage
+- Similar to Nature/Science early screening model
+
+**Full Review criteria:**
+- Advances in core ASPLOS disciplines (not just using them)
+- Quality of system design and implementation
+- Major Revision decision available
+
+## SOSP 2026 Reviewer Perspective
+
+**Core evaluation:**
+- Novelty, significance, interest, clarity, relevance, correctness
+- Encourages groundbreaking work in significant new directions
+- Different evaluation criteria for new problems vs established areas
+
+**Author Response:**
+- Limited to: correcting factual errors + addressing reviewer questions
+- NO new experiments or additional work
+- Keep under 500 words
+
+**Artifact Evaluation:**
+- Optional but encouraged
+- Cooperative process: authors can fix issues during evaluation
+- Register within days of acceptance notification
+
+## ML vs Systems: Key Review Differences
+
+| Aspect | ML/AI Venues | Systems Venues |
+|--------|-------------|---------------|
+| **Page limit** | 7-9 pages | 12 pages |
+| **Evaluation focus** | Benchmarks, ablations, metrics | End-to-end system performance, real workloads |
+| **Implementation** | Code often optional | Working system expected |
+| **Novelty** | New methods/insights | New system designs/approaches |
+| **Reproducibility** | Checklist-based | Artifact evaluation (optional) |
+| **Template** | Venue-specific `.sty` | USENIX `.sty` or ACM `acmart.cls` |
+| **Review process** | Single deadline | Often dual deadlines |
+
+## Systems-Specific Common Concerns
+
+| Concern | How to Pre-empt |
+|---------|-----------------|
+| "Just an ML paper, not systems" | Emphasize system design, architecture decisions, deployment challenges |
+| "Evaluation only on microbenchmarks" | Include end-to-end evaluation with real workloads |
+| "No working prototype" | Build and evaluate a real system, not just simulate |
+| "Deployment not realistic" | Show real-world applicability, discuss practical constraints |
+| "Not relevant to systems community" | Frame contributions in systems terms, cite systems papers |
+| "ASPLOS: Not advancing arch/PL/OS" | Explicitly state how work advances core disciplines |