biome-code-review

1---2name: biome-code-review3description: Use only for reviewing completed Biome PRs, branches, commit ranges, diffs, or working trees against business logic and requirements. Excludes broad code-quality and process audits, triage, reproduction, and implementation.4compatibility: Designed for read-only review of the Biome codebase (github.com/biomejs/biome).5metadata:6  repository: biomejs/biome7  mode: read-only8---9 10# Biome Code Review11 12Review changes read-only against business requirements and applicable behavioral, architectural, and subsystem constraints.13 14## Invocation15 16Delegate completed reviews to a fresh subagent when available. Supply only:17 18- the review scope;19- the intended business requirements, including constraints the repository cannot establish.20 21To avoid bias, omit implementation details, suspected defects, priority files, prior findings, and expected review outcomes.22 23Review subagents must not delegate again. Without subagents, review the complete scope directly.24 25Treat delegated findings as candidates; the parent must [validate them](#parent-validation) before confirming or acting.26 27## Safety Boundary28 29Reviewers and validating parents must preserve the worktree. Authorized implementation follows validation, outside this skill.30 31- Do not create, edit, move, or delete files.32- Do not run project code, builds, tests, formatters, linters, codegen, benchmarks, package managers, LSPs, or daemons.33- Do not run mutating Git or GitHub commands except the single base-branch fetch allowed below.34- Do not use shell pipelines, scripts, `sed`, or `awk` to inspect source. Use file reads, globs, and text search.35 36Shell is limited to these review commands:37 38```text39git fetch origin <main|next>40git status --short --branch --untracked-files=all41git branch --show-current42git rev-parse ...43git merge-base ...44git --no-pager diff --no-ext-diff --no-textconv ...45git --no-pager show --no-ext-diff --no-textconv ...46git --no-pager log ...47git ls-files ...48gh pr view <number> [--json ...]49gh pr diff <number>50gh issue view <number> [--json ...]51```52 53One fetch of the resolved base is allowed. If it fails, continue with the local remote-tracking branch and disclose that it may be stale. Documentation lookups are allowed only when checked-out source cannot settle an external language or API contract.54 55## Establish Scope56 57Use the supplied PR, range, diff, files, or base; exclude unrelated worktree changes.58 59For a PR number, read its title, body, base, and files with `gh pr view`, then read `gh pr diff`. Do not check it out.60 61When no explicit PR, range, diff, or file scope is supplied, review the current branch and working tree:62 631. Read branch, upstream, and every untracked path with `git status --short --branch --untracked-files=all`.642. Use the supplied base when present. Otherwise, use the tracking branch when it is `origin/main` or `origin/next`, or compare merge bases against both branches and choose the actual ancestor. Ask only when the result is genuinely ambiguous.653. Fetch the selected base once.664. Diff the merge base through the working tree so committed, staged, and unstaged changes are included.675. Read every reported untracked file; untracked tests and changesets are part of the review.68 69Never fall back to `HEAD` as the base without saying so. That would omit committed branch changes.70 71Infer intent from the brief, PR/commit text, linked issue, tests, and code; explicit requirements take precedence. A steered brief still requires reviewing the entire supplied scope; disclose the steer.72 73## Behavioral Boundary74 75Before tracing beyond the diff, record intended behavior, requirements, and applicable behavioral, architectural, and subsystem constraints with sources. Report violations or concrete avoidable costs/failures introduced, worsened, or newly exposed by the change.76 77Read surrounding code only to verify changed behavior and constraints; full-file reads do not expand scope. Stop tracing once the question is settled.78 79Apply guidance only to changed or directly affected code; preferences are not violations, and requirements must not be invented. Exclude unrelated cleanup, defects, process checks, and speculative optimization, even from optional suggestions or questions.80 81## Gather Context82 83- Read every changed file in full.84- Inspect affected callers, registrations, generated counterparts, neighbors, and tests only to verify scoped behavior and constraints.85- Read root `AGENTS.md` and only the relevant sections of `CONTRIBUTING.md` or crate guides.86- Load relevant skills and references for contracts, not additional objectives or permission to execute workflows.87- Prefer checked-out source over documentation or memory.88 89Use this routing table instead of loading every reference:90 91| In-scope question concerns | Load |92| --- | --- |93| Grammar, lint, parser, formatter, diagnostics, types, tests, generated files | [repository-and-subsystems.md](references/repository-and-subsystems.md) and the matching implementation skill |94| `biome_service`, workspace DB, CLI/LSP execution, cancellation | [workspace-access.md](references/workspace-access.md) |95| Rust production totality, failure paths, recursion, syntax text, ranges, allocation, or API shape | [rust-safety-and-syntax.md](references/rust-safety-and-syntax.md) |96| Documentation describing required behavior or affected contracts | [documentation-and-process.md](references/documentation-and-process.md) |97 98## Review Method99 100Perform two passes:101 1021. **Behavior:** trace requirements, control and data flow, and relevant ownership and execution contracts.1032. **Implementation:** inspect every human-written changed line and relevant test against those requirements and affected behavior.104 105Try to falsify claimed requirements such as zero-copy, unchanged behavior, faster execution, or no new dependencies. Rate counterexamples by impact.106 107Check required paths, callers, variants, and failure behavior before supporting artifacts. Behavioral failures require reachability; constraint violations, including [production totality](#production-totality), require evidence of an unmet constraint, not a runtime counterexample.108 109## Cross-Cutting Checks110 111- Verify a bug fix's regression test reaches the changed behavior and fails without the fix.112- Read snapshot changes as expected behavior. A snapshot can faithfully record an incorrect range, message, or output.113- A safe fix must preserve semantics for every reachable case and stop the rule from reporting after application.114- Check required registration and generated artifacts against affected sources and `AGENTS.md`; honor CI Autofix exceptions.115- Consolidate repeated symptoms under their root cause.116 117## Finding Threshold118 119Report only actionable, in-scope issues supported by inspected code.120 121- Cite the unmet requirement, violated contract, or concrete avoidable cost and its connection to the diff.122- For behavioral failures, give the trigger, expected versus actual behavior, and impact. For test gaps, name the required scenario and defect to catch.123- Check guards, types, caller invariants, and tests for counter-evidence.124- Cite the smallest relevant changed range.125- Give minimal remediation, not a patch.126 127Put unresolved in-scope requirements or correctness assumptions under questions, not findings.128 129### Production Totality130 131Report production `unwrap`, `expect`, indexing, slicing, panic macros, integer division/remainder, and other partial operations unless release-mode control flow, types, or API contracts establish totality. No concrete failing input is required.132 133Limit this to added or modified operations, or existing operations whose preconditions or reachability the diff affects. Check relevant guards and callers; proofs need not be local.134 135Cite the unmet precondition and inspected evidence without claiming a demonstrated panic. See [operation-specific checks](references/rust-safety-and-syntax.md#partial-operations).136 137## Parent Validation138 139Validate every candidate independently; confidence is not evidence.140 1411. Read the cited diff, source, callers or tests, and claimed requirement, constraint, or cost; the summary is not evidence.1422. Try to disprove claims using guards, types, call order, tests, and pre-change behavior. Behavioral failures require reachability; totality findings require checking release-mode control flow, types, and API contracts, not a failing input.1433. Apply the same scope and finding threshold; verify applicable constraints, avoidable costs, and proportional remediation. Reject out-of-scope claims even if correct; never invent requirements.1444. Mark each **validated**, **rejected**, or **unresolved**, citing supporting or specific missing evidence. Seek targeted clarification when needed.1455. Only validated findings qualify for confirmation or authorized remediation outside review. Note rejected/unresolved candidates in validation status; unresolved requirements belong under questions and never justify fixes.146 147## Report Format148 149Return only raw Markdown in one fenced block, findings first by severity.150 151Every finding starts with exactly one `<severity>/<area>` token.152 153| Severity | Meaning |154| --- | --- |155| `high` | Material regression, corruption or data loss, exploitable security/privacy failure, availability failure, broad false positive, incorrect safe fix, user-reachable panic, or a change that defeats its core requirement |156| `medium` | Credible edge-case failure, missing required variant or registration, demonstrated performance regression, material test gap for required behavior, or unjustified in-scope production partial operation |157| `low` | Localized correctness, maintainability, documentation, or implementation-constraint issue that meets the finding threshold |158 159Areas: `design`, `correctness`, `security`, `privacy`, `availability`, `performance`, `completeness`, `error-handling`, `tests`, `maintainability`, `documentation`, `changeset`, `process`.160 161Areas classify eligible findings; they do not expand scope.162 163Use exactly this format:164 165````md166```167## Findings168 169- `high/correctness` `path/to/file.rs:42` - Short title. Cite the requirement, trigger, expected/actual behavior, impact, and minimal remediation.170- `medium/error-handling` `path/to/file.rs:57` - Missing totality guarantee. Cite the affected operation, unmet precondition, inspected evidence, and minimal remediation; do not claim a demonstrated panic.171 172## Questions173 174- Include only unresolved assumptions that affect correctness. Omit this section when there are none.175 176## Review Status177 178Scope: `<supplied diff or base-sha through head or working tree>`, `<n>` files, plus listed in-scope untracked files.179Requirements: `<intended behavior, applicable constraints, and sources>`.180Brief: independent | steered toward `<area>`; full supplied scope reviewed.181Validation: Static review only; no project code was run.182Parent validation: not delegated | pending: parent must independently check source and requirements before confirming or acting | completed: `<evidence-backed candidate dispositions>`.183Fetch: updated `origin/<base>` | failed, local `origin/<base>` used | not needed.184```185````186 187Use `No findings.` under `## Findings` when empty. Severity reflects impact, not confidence. Subagents mark parent validation pending; only the parent may mark it completed after validation.188