/biome-code-review

name: biome-code-review
description: Static, read-only code review of a Biome (github.com/biomejs/biome) pull request, local branch, commit range, diff, or working tree being prepared as a PR. Applies Biome's own conventions - nursery placement and naming for lint rules, diagnostics quality, allocation and borrow discipline around TokenText and SyntaxToken, parser error recovery, formatter IR and idempotency, codegen freshness, insta snapshots, dev-dependency paths, doc style, changesets, branch targeting, PR titles, and AI disclosure. Only when asked to review a Biome pull request, branch, commit range, diff, or working tree. Not for issue triage, bug reproduction, or implementing fixes. Reports findings only - never edits files or runs cargo, just, pnpm, tests, builds, or codegen.
compatibility: Designed for read-only review of the Biome codebase (github.com/biomejs/biome).
metadata:
  repository: biomejs/biome
  mode: read-only

Biome Code Review

Review a proposed change for correctness and fit with the Biome codebase.

Safety Boundary

This is a static review. Preserve the developer's working tree exactly as found.

• Do not create, edit, move, or delete files. Do not apply patches. Do not create a changeset.
• Do not run project code: no `cargo` (including `check`, `test`, `clippy`, `insta`), no `just`, `pnpm`, `npm`, `bun`, `node`, no codegen, benchmarks, `prettier-compare`, LSP, or daemon.
• Do not run mutating Git: no pull, merge, rebase, checkout, switch, worktree, reset, restore, clean, stash, commit, push, or `gh pr review|comment|edit|merge|close`.
• Do not use `curl`, `wget`, or arbitrary network tools.
• Do not use shell pipelines, `sed`, `awk`, or scripts to analyze source. Use file-reading, glob, and text-search tools.
• Do not delegate the review to another agent — the restrictions may not carry over. Loading a skill from the repository's `.claude/skills/` is **not** delegation; it pulls maintainer-authored instructions into this context and is expected.

Shell is limited to this allowlist:

git fetch origin main
git fetch origin next
git status --short --branch
git branch --show-current
git rev-parse ...
git merge-base ...
git --no-pager diff --no-ext-diff --no-textconv ...
git --no-pager show --no-ext-diff --no-textconv ...
git --no-pager log ...
git ls-files ...
gh pr view <number> [--json ...]
gh pr diff <number>
gh issue view <number> [--json ...]

Permitted network operations, and nothing else:

1. One `git fetch` of the base branch. It updates Git metadata, not source files. If it fails, continue with the local `origin/<base>` and disclose that the comparison may be stale; do not retry. 2. The read-only `gh` reads above, when the user supplies a PR number or the description cites `Fixes #N` and you need the issue to judge changeset accuracy or test coverage. 3. Documentation lookups when the checked-out source cannot settle the question: `biomejs.dev`, `docs.rs`, `doc.rust-lang.org`, `rust-lang.github.io/rust-clippy`, and MDN or a language spec when the change encodes a claim about JS, CSS, HTML, or GraphQL semantics.

Prefer the checked-out source over documentation and over memory. A rule's behavior, an API's contract, and a lint's registration are all determinable from the repository.

Delegating This Review

An orchestrator may spawn agents that each run this skill; the Safety Boundary forbids only delegating outward from inside a review. The brief is the failure mode: a hint narrowing where the agent looks returns that suspicion with citations attached, and steering destroys the findings the brief did not anticipate.

**Brief the agent with the scope and nothing else.** A PR number, a branch, a commit range, or a diff. Add the feature's intended behavior only where the repository cannot supply it — a product requirement, an off-repo decision, an issue the agent cannot read. That is the complete brief.

**Never include** the area you suspect, the file you think is wrong, a defect class to prioritize, a severity or finding count you expect, or the earlier review whose gaps prompted this one. Both "check the allocations in `x.rs`" and "focus on the parser" substitute your judgment for the agent's, and guarantee the rest of the diff is reviewed at lower attention or not at all.

**Running this skill under a brief that steers:** keep the scope, discard the steer. Review the whole diff against this file's priorities as though the pointer had not arrived, and report what that produces — including no finding in the named area when it is clean. Note the steer under `## Review Status` so a confirmation is not read as an independent result.

Establish the Review Scope

Prefer a scope the user supplies: files, a diff, a commit range, a base branch, or a PR number.

Biome has two long-lived branches. `main` takes bug fixes, new nursery rules, and internal-only changes; `next` takes features, nursery promotions, and breaking changes. Determine the **actual** base first, then judge separately whether it is the **correct** one.

For a PR number, read `gh pr view <n> --json title,body,baseRefName,files` and `gh pr diff <n>`. Do not check it out.

Otherwise review the current branch and working tree:

1. Read the branch and upstream with `git status --short --branch`. 2. Pick the base: the tracking branch if it is `origin/main` or `origin/next`; otherwise compute the merge base against both and take the branch whose merge base is a descendant of the other. If genuinely ambiguous, ask. Never fall back to `HEAD`: it reviews only uncommitted work and drops every commit on the branch without saying so. 3. Fetch that base once. 4. Diff merge-base to working tree — this covers committed, staged, and unstaged changes. 5. Use `git status` to identify untracked file paths, then read the contents of each with the file-reading tool. New rules, specs, and `.changeset/*.md` entries are frequently untracked.

Establish intended behavior from the description, comm