/pull-request
Guide for creating proper pull requests for the Biome project. Use when opening a PR, writing a PR description, choosing the correct target branch, or filling out the PR template. Trigger when creating PRs, writing PR summaries, or preparing code for review.
$ npx -y skills add biomejs/biome --skill pull-request --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/pull-request
Context preview
The summary Claude sees to decide when to auto-load this skill.
Guide for creating proper pull requests for the Biome project. Use when opening a PR, writing a PR description, choosing the correct target branch, or filling out the PR template. Trigger when creating PRs, writing PR summaries, or preparing code for review.
SKILL.md
pull-request.SKILL.mdname: pull-request
description: Guide for creating proper pull requests for the Biome project. Use when opening a PR, writing a PR description, choosing the correct target branch, or filling out the PR template. Trigger when creating PRs, writing PR summaries, or preparing code for review.
compatibility: Designed for coding agents working on the Biome codebase (github.com/biomejs/biome).
Purpose
Use this skill when creating a pull request for the Biome repository. It covers branch targeting, title formatting, the PR template, and AI disclosure requirements.
AI Assistance Disclosure
If AI was used in any capacity to produce the PR, **you must disclose it** in the PR description. Examples:
> This PR was written primarily by Claude Code. > > I consulted ChatGPT to understand the codebase but the solution was fully authored manually by myself.
This is mandatory. It helps reviewers apply appropriate scrutiny.
Choose the Target Branch
| Change type | Target branch | | --- | --- | | Bug fix (code or docs) | `main` | | New **nursery** rule | `main` | | Rule promotion from nursery | `next` | | New feature (user-facing) | `next` | | New feature (internal only) | `main` |
PR Title
Use **conventional commit format**. The title becomes the squash-merge commit message.
<type>(<scope>): <short description>
Supported prefixes:
- `feat:` — new feature
- `fix:` — bugfix
- `docs:` — documentation update
- `refactor:` — code refactor (no behavior change)
- `test:` — test update
- `chore:` — housekeeping
- `perf:` — performance improvement
- `ci:` — CI change
- `build:` — build system or dependency change
- `revert:` — revert a previous change
Examples:
feat(css): add noDuplicateSelectors rule
fix(linter): handle edge case in useOptionalChain
docs: update contributing guide
refactor(parser): simplify HTML attribute parsing
The CI runs [action-semantic-pull-request](https://github.com/amannn/action-semantic-pull-request) to validate the title. Fix it if the workflow fails.
PR Template
The repository has a PR template at `.github/PULL_REQUEST_TEMPLATE.md`. Every PR description must follow this structure:
## Summary
<!-- Explain the motivation for this change. What problem does it solve? -->
<!-- Link relevant issues or Discord discussions. -->
<!-- If user-facing, mention the changeset. -->
## Test Plan
<!-- What demonstrates correctness? Mention tests added/updated. -->
## Docs
<!-- For new rules/actions/options: docs are inline in the code (rustdoc). -->
<!-- For other features: link a docs PR to the `next` branch of biomejs/website. -->
Writing a Good Summary
- **Bug fixes**: Explain the fix concisely. If the fix introduces exceptions or unusual code paths, call those out so reviewers know what to watch for.
- **New concepts**: If the PR adds new abstractions, types, or patterns to the codebase, explain the technical design so reviewers can evaluate it.
- **General rule**: Provide enough context for reviewers to understand how to review the PR. The summary serves the reviewer.
- Link related issues: `Fixes #1234` or `Related to #5678`.
- A changeset description is a good starting point, but the summary should add context the changelog alone would not convey (design decisions, trade-offs, scope limitations).
Test Plan
Keep it brief. Examples:
- "Added new tests from the bug report."
- "Extended existing snapshot tests to cover the new edge case."
Do not list individual test files — the diff speaks for itself. If automated tests were not possible, state that manual testing is required.
Docs
- New features require documentation. This section is for linking the PR against the `next` branch of [biomejs/website](https://github.com/biomejs/website/).
- Lint rules and helps to carry their own docs as rustdoc in the source code — no separate website PR needed.
- If the PR doesn't need for documentation changes, add `N/A` under the section.
Pre-PR Checklist
Before opening, ensure:
1. Code compiles: `cargo check` 2. Tests pass: `cargo test` (or `just test-crate <crate>` for scoped runs) 3. Code is formatted: `just f` 4. Lints pass: `just l` 5. Code generation is up to date (CI autofix handles this, but check if unsure):
- Lint rules: `just gen-rules && just gen-configuration`
- Grammar: `just gen-grammar <lang>`
- Bindings: `just gen-bindings`
6. Changeset created (if user-facing change): `just new-changeset-empty` 7. Snapshot tests reviewed: `cargo insta review`
References
- Contribution guide: `CONTRIBUTING.md` sections "Commit messages" and "Creating pull requests"
- PR template: `.github/PULL_REQUEST_TEMPLATE.md`
- Conventional commits: https://www.conventionalcommits.org/en/v1.0.0-beta.2/
- Versioning policy: https://biomejs.dev/internals/versioning/
Read more
name: pull-request description: Guide for creating proper pull requests for the Biome project. Use when opening a PR, writing a PR description, choosing the correct target branch, or filling out the PR template. Trigger when creating PRs, writing PR summaries, or preparing code for review. compatibility: Designed for coding agents working on the Biome codebase (github.com/biomejs/biome).
Purpose
Use this skill when creating a pull request for the Biome repository. It covers branch targeting, title formatting, the PR template, and AI disclosure requirements.
AI Assistance Disclosure
If AI was used in any capacity to produce the PR, **you must disclose it** in the PR description. Examples:
> This PR was written primarily by Claude Code. > > I consulted ChatGPT to understand the codebase but the solution was fully authored manually by myself.
This is mandatory. It helps reviewers apply appropriate scrutiny.
Choose the Target Branch
| Change type | Target branch | | --- | --- | | Bug fix (code or docs) | `main` | | New **nursery** rule | `main` | | Rule promotion from nursery | `next` | | New feature (user-facing) | `next` | | New feature (internal only) | `main` |
PR Title
Use **conventional commit format**. The title becomes the squash-merge commit message.
<type>(<scope>): <short description>
Supported prefixes:
- `feat:` — new feature
- `fix:` — bugfix
- `docs:` — documentation update
- `refactor:` — code refactor (no behavior change)
- `test:` — test update
- `chore:` — housekeeping
- `perf:` — performance improvement
- `ci:` — CI change
- `build:` — build system or dependency change
- `revert:` — revert a previous change
Examples:
feat(css): add noDuplicateSelectors rule fix(linter): handle edge case in useOptionalChain docs: update contributing guide refactor(parser): simplify HTML attribute parsing
The CI runs [action-semantic-pull-request](https://github.com/amannn/action-semantic-pull-request) to validate the title. Fix it if the workflow fails.
PR Template
The repository has a PR template at `.github/PULL_REQUEST_TEMPLATE.md`. Every PR description must follow this structure:
## Summary <!-- Explain the motivation for this change. What problem does it solve? --> <!-- Link relevant issues or Discord discussions. --> <!-- If user-facing, mention the changeset. --> ## Test Plan <!-- What demonstrates correctness? Mention tests added/updated. --> ## Docs <!-- For new rules/actions/options: docs are inline in the code (rustdoc). --> <!-- For other features: link a docs PR to the `next` branch of biomejs/website. -->
Writing a Good Summary
- **Bug fixes**: Explain the fix concisely. If the fix introduces exceptions or unusual code paths, call those out so reviewers know what to watch for.
- **New concepts**: If the PR adds new abstractions, types, or patterns to the codebase, explain the technical design so reviewers can evaluate it.
- **General rule**: Provide enough context for reviewers to understand how to review the PR. The summary serves the reviewer.
- Link related issues: `Fixes #1234` or `Related to #5678`.
- A changeset description is a good starting point, but the summary should add context the changelog alone would not convey (design decisions, trade-offs, scope limitations).
Test Plan
Keep it brief. Examples:
- "Added new tests from the bug report."
- "Extended existing snapshot tests to cover the new edge case."
Do not list individual test files — the diff speaks for itself. If automated tests were not possible, state that manual testing is required.
Docs
- New features require documentation. This section is for linking the PR against the `next` branch of [biomejs/website](https://github.com/biomejs/website/).
- Lint rules and helps to carry their own docs as rustdoc in the source code — no separate website PR needed.
- If the PR doesn't need for documentation changes, add `N/A` under the section.
Pre-PR Checklist
Before opening, ensure:
1. Code compiles: `cargo check` 2. Tests pass: `cargo test` (or `just test-crate <crate>` for scoped runs) 3. Code is formatted: `just f` 4. Lints pass: `just l` 5. Code generation is up to date (CI autofix handles this, but check if unsure):
- Lint rules: `just gen-rules && just gen-configuration`
- Grammar: `just gen-grammar <lang>`
- Bindings: `just gen-bindings`
6. Changeset created (if user-facing change): `just new-changeset-empty` 7. Snapshot tests reviewed: `cargo insta review`
References
- Contribution guide: `CONTRIBUTING.md` sections "Commit messages" and "Creating pull requests"
- PR template: `.github/PULL_REQUEST_TEMPLATE.md`
- Conventional commits: https://www.conventionalcommits.org/en/v1.0.0-beta.2/
- Versioning policy: https://biomejs.dev/internals/versioning/
A toolchain for web projects, aimed to provide functionalities to maintain them. Biome offers formatter and linter, usable via CLI and LSP.
Repo: biomejs/biome
Other skills on biome.
- /biome-code-review
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
Open skill - /biome-developer
General development best practices and common gotchas when working on Biome. Use for avoiding common mistakes, understanding Biome-specific patterns (AST, syntax nodes, string extraction, embedded languages), and learning technical tips.
Open skill - /changeset
Guide for creating and writing proper changesets for Biome PRs. Use when a PR introduces user-visible changes (bug fixes, new features, rule changes, formatter changes, parser changes) that need a changeset entry for the CHANGELOG. Trigger when creating changesets, writing
Open skill - /diagnostics-development
Guide for creating high-quality, user-friendly diagnostics in Biome. Use when creating diagnostics for lint rules, adding helpful advice to error messages, implementing code frame displays, or improving diagnostic quality.
Open skill - /doc-comments
How to write inline comments, rustdoc, and module documentation in the Biome codebase. The audience is Biome developers reading the source, not end users. Use whenever writing or editing `//` comments, `///` item docs, or `//!` module docs — including comments added incidentally
Open skill - /eslint-migrate-options
Guide for implementing ESLint-to-Biome rule option migrators inside `biome migrate eslint`. Use whenever you add or update a Biome lint rule that has an ESLint source rule with configurable options, need to deserialize plugin-specific ESLint options, or need custom migration
Open skill

