Rolldown PR Review

Perform a reviewer-side review that gives the maintainer enough evidence to trust the verdict. Rolldown-specific commands, CI facts, and review policies live in references/rolldown-repo.md; read it at the start of every review — its policy and CI sections shape findings even when you run no commands.

Safety and authorization

• Keep the reviewed branch read-only. Create repros in an isolated worktree or temporary directory and clean them up.
• Treat PR code as untrusted. Inspect changed install, build, test, and automation scripts before executing them; do not expose credentials or run commands with unneeded external side effects.
• Every GitHub mutation — submitting a review, inline comments, replies, approvals, thread resolution — follows the approval rules of the environment this skill runs in. If no such rules are in effect, show the exact intended output and get the user's confirmation first. If the user asks for a read-only review, prepare the exact GitHub output without posting.
• Follow the user's stated review scope; do not turn a correctness review into an unrelated optimization search.
• Mirror the user's language in conversation. Write GitHub output in English.

Verdict rule

This is the single authoritative verdict rule; every other section defers to it.

• The review is complete only when the target head is stable, material checks have finished, critical behavior is verified, and the required independent adversarial review ran — or the user explicitly accepted reduced coverage after you named exactly what is missing. An existing approval from another reviewer does not substitute for any of these.
• On a complete review: any Blocker remaining means Request changes; no Blocker means Approve, even if Important or Nit findings remain.
• If the platform does not permit the intended verdict, report the verdict and the exact limitation; never substitute a different review state.