Peer Review
Read ../researchstack/references/venues.md, ../researchstack/references/review-rubric.md, ../researchstack/references/conference-story-patterns.md, ../researchstack/references/expert-advice.md, and ../researchstack/references/memory.md.
If prior project memory exists, use it carefully:
- treat remembered reviewer risks as hypotheses to re-check,
- treat remembered venue targets as current intent unless contradicted,
- separate old known weaknesses from new weaknesses discovered in this review.
Write like a serious reviewer, not a friendly editor. Do not treat topic popularity as a proxy for method novelty.
Structure the review as:
- Summary of the paper and claimed contribution.
- Strengths.
- Weaknesses.
- Detailed questions.
- Recommendation with confidence.
Run distinct reviewer lenses before combining the verdict:
- Problem and positioning: significance, topic state, closest topic and method work.
- Method and systems design: method delta, mechanism chain, design alternatives, semantic integrity, and deployment cost.
- Evaluation and artifact: rival predictions, baseline fairness, end-to-end boundary, reproducibility, and external validity.
- Communication: whether claims, sources, figures, and limitations can be audited.
Report disagreements between lenses instead of forcing false consensus.
Use venue-appropriate standards. For example:
- ICLR: novelty and empirical rigor.
- ASPLOS: cross-layer depth and realistic evaluation.
- SC: scaling credibility and HPC realism.
- EuroSys/OSDI: system design, implementation realism, operational lessons, and SLO/cost/reliability evidence.
- NSDI/SIGCOMM: deployment relevance, robustness, and network realism.
Use the expert-advice checks when relevant:
- Levin/Redell: new idea, reality, lessons, focus.
- Irene Zhang: why/how/results, Y/Z target setting, alternatives for each design choice.
- Kayvon Fatahalian: goals, non-goals, constraints, design decisions, and causal evaluation.
- Gernot Heiser: benchmarking crimes.
Be precise about whether a weakness is fatal or fixable.
If the topic is crowded but the method is distinct, review the method on its merits. If the method is weak, state which design-space dimension or experiment could repair it before recommending a topic change.
If the paper is weak, explain why it would likely be rejected even if the writing were improved.
When the review surfaces a durable rejection pattern, venue-specific sensitivity, or claim/evidence mismatch that future sessions should remember, propose a project-memory entry.
1---2name: researchstack-peer-review-23description: Strict conference-style review skill for computer science papers. Use when Codex should simulate expert reviewers for venues such as ICLR, ASPLOS, SC, NSDI, or SIGCOMM, produce a structured review, assign confidence, explain likely acceptance risk, and identify the most damaging objections a real PC member might raise.4---56<!-- AUTO-GENERATED for codex from researchstack v0.3.0. Edit source SKILL.md files, then regenerate from the source checkout. -->78# Peer Review910Read [../researchstack/references/venues.md](../researchstack/references/venues.md), [../researchstack/references/review-rubric.md](../researchstack/references/review-rubric.md), [../researchstack/references/conference-story-patterns.md](../researchstack/references/conference-story-patterns.md), [../researchstack/references/expert-advice.md](../researchstack/references/expert-advice.md), and [../researchstack/references/memory.md](../researchstack/references/memory.md).1112If prior project memory exists, use it carefully:1314- treat remembered reviewer risks as hypotheses to re-check,15- treat remembered venue targets as current intent unless contradicted,16- separate old known weaknesses from new weaknesses discovered in this review.1718Write like a serious reviewer, not a friendly editor. Do not treat topic popularity as a proxy for method novelty.1920Structure the review as:2122- Summary of the paper and claimed contribution.23- Strengths.24- Weaknesses.25- Detailed questions.26- Recommendation with confidence.2728Run distinct reviewer lenses before combining the verdict:2930- **Problem and positioning**: significance, topic state, closest topic and method work.31- **Method and systems design**: method delta, mechanism chain, design alternatives, semantic integrity, and deployment cost.32- **Evaluation and artifact**: rival predictions, baseline fairness, end-to-end boundary, reproducibility, and external validity.33- **Communication**: whether claims, sources, figures, and limitations can be audited.3435Report disagreements between lenses instead of forcing false consensus.3637Use venue-appropriate standards. For example:3839- ICLR: novelty and empirical rigor.40- ASPLOS: cross-layer depth and realistic evaluation.41- SC: scaling credibility and HPC realism.42- EuroSys/OSDI: system design, implementation realism, operational lessons, and SLO/cost/reliability evidence.43- NSDI/SIGCOMM: deployment relevance, robustness, and network realism.4445Use the expert-advice checks when relevant:4647- Levin/Redell: new idea, reality, lessons, focus.48- Irene Zhang: why/how/results, Y/Z target setting, alternatives for each design choice.49- Kayvon Fatahalian: goals, non-goals, constraints, design decisions, and causal evaluation.50- Gernot Heiser: benchmarking crimes.5152Be precise about whether a weakness is fatal or fixable.5354If the topic is crowded but the method is distinct, review the method on its merits. If the method is weak, state which design-space dimension or experiment could repair it before recommending a topic change.5556If the paper is weak, explain why it would likely be rejected even if the writing were improved.5758When the review surfaces a durable rejection pattern, venue-specific sensitivity, or claim/evidence mismatch that future sessions should remember, propose a project-memory entry.
lqf0624