name	researchstack-peer-review
description	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.

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.

Structure the review as:

Summary of the paper and claimed contribution.
Strengths.
Weaknesses.
Detailed questions.
Recommendation with confidence.

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 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.

Peer Review

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.

Structure the review as:

Summary of the paper and claimed contribution.

Strengths.

Weaknesses.

Detailed questions.

Recommendation with confidence.

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 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.

researchstack-peer-review

Peer Review

このリポジトリの他の Skills

このリポジトリの他の Skills

Peer Review