Official agent skill

Formatter Development

by biomejs in biomejs/biome

A skill your agent uses whenever implementing or debugging Biome formatter behavior, IR composition, node rules, layout selection, source-comment handling, verbatim formatting, idempotency, internal…

OfficialApache-2.0Auto-check passedDevelopment

Install Formatter Development

skills CLI
$ npx skills add biomejs/biome --skill formatter-development -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install biomejs/biome formatter-development --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/biomejs/biome.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.agents/skills/formatter-development .claude/skills/formatter-development && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
formatter-development
GitHub stars
26k
Token cost
~2.1k tokens
SKILL.md length
1,075 words
Files
1
Skills in repo
12
Repo updated
First seen
Licence
Apache-2.0

At a glance

A skill your agent uses whenever implementing or debugging Biome formatter behavior, IR composition, node rules, layout selection, source-comment handling, verbatim formatting, idempotency, internal…

  • Works in 6 steps: Reproduce the behavior with a focused… → Inspect the node fields, comments, and… → Implement the smallest layout change… → …
  • Debugging Biome formatter behavior
  • SKILL.md covers Workflow, Printing Discipline, Node Rules and Token Rules, plus 8 more sections
  • Calls bun and just

What it does

Formatter Development is an agent skill from biomejs/biome, published by the product's own GitHub organization. Use this skill whenever implementing or debugging Biome formatter behavior, IR composition, node rules, layout selection, source-comment handling, verbatim formatting, idempotency, internal specs, or Prettier comparison. Do not use it for generic snapshot commands or parser changes.

Its SKILL.md is about 2.1k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts. Compatibility notes: Designed for coding agents working on the Biome codebase (github.com/biomejs/biome).

It sits in Development, covering Linting and formatting. It works with Prettier. The repository describes itself as: A toolchain for web projects, aimed to provide functionalities to maintain them. Biome offers formatter and linter, usable via CLI and LSP. The licence is Apache-2.0.

When your agent uses it

  • Debugging Biome formatter behavior
  • Layout selection
  • Source-comment handling
  • Verbatim formatting

Example prompts

  • “/formatter-development”

Requirements

  • Compatibility (from SKILL.md): Designed for coding agents working on the Biome codebase (github.com/biomejs/biome).

Workflow steps

6 steps, taken from the first numbered list in SKILL.md.

  1. Reproduce the behavior with a focused internal formatter spec or quick_test.
  2. Inspect the node fields, comments, and nearby formatting rules.
  3. Implement the smallest layout change using formatter IR.
  4. Run focused formatter tests and inspect snapshots.
  5. Compare with Prettier when compatibility is relevant.
  6. Format and lint before committing.

What it can do on your machine

Read from SKILL.md and the folder at commit c870caa. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • bun
    • just

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

  • Compatibility

    Designed for coding agents working on the Biome codebase (github.com/biomejs/biome).

    From compatibility in the SKILL.md frontmatter.

Context cost

Formatter Development loads about 2.1k tokens when it runs. Until then it costs about 76 tokens; SKILL.md has 1,075 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~76
When it runs · the whole SKILL.md, loaded when a task matches
~2.1k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from biomejs/biome at commit c870caa, republished under its Apache-2.0 licence (© biomejs). 1,075 words, ~2,148 tokens.

Download SKILL.mdSave it as .claude/skills/formatter-development/SKILL.md (or your agent's skills folder).
name
formatter-development
description
Use this skill whenever implementing or debugging Biome formatter behavior, IR composition, node rules, layout selection, source-comment handling, verbatim formatting, idempotency, internal specs, or Prettier comparison. Do not use it for generic snapshot commands or parser changes.
compatibility
Designed for coding agents working on the Biome codebase (github.com/biomejs/biome).

Formatter Development

Use crates/biome_formatter/CONTRIBUTING.md and the language formatter's guide as the canonical architecture references. Inspect neighboring node implementations before selecting IR primitives.

Workflow

  1. Reproduce the behavior with a focused internal formatter spec or quick_test.
  2. Inspect the node fields, comments, and nearby formatting rules.
  3. Implement the smallest layout change using formatter IR.
  4. Run focused formatter tests and inspect snapshots.
  5. Compare with Prettier when compatibility is relevant.
  6. Format and lint before committing.

Printing Discipline

Formatter output is a structured rewrite of the source tree, not a fresh pretty-printer. Treat every missed node, missed token, unchecked suppression, and untracked replacement as a formatter bug, not as style feedback.

  • Every source token in the formatted range MUST be consumed exactly once. A token is consumed only by formatting it, removing it with format_removed, replacing it with format_replaced, or by a language-specific helper that does one of those operations.
  • Every source node in the formatted range MUST be handled every time. Prefer node.format() or node.format().with_options(...) so the node's own rule formats the node, checks suppressions, and routes comments through the formatter infrastructure.
  • A parent formatter MUST NOT inline a child node's fields just to get a convenient layout. Move the layout decision into the child rule or pass options into the child formatter.
  • If an architecture-specific formatter bypasses a node's rule, it MUST NOT skip the node silently. It MUST check f.context().comments().is_suppressed(node.syntax()); if the node is suppressed, it MUST write the language's format_suppressed_node(...) helper instead of formatting the node body. Without this check, debug builds fail suppression coverage and user suppressions can be ignored.
  • Source tokens MUST be printed through their typed accessors. Use token("...") only for syntax inserted by the formatter when no source token exists.
  • Removing a source token from output MUST use format_removed(&token). Do not drop the field, bind it to _, or omit it from write! without consuming it through format_removed; skipped trivia still belongs to that token.
  • Replacing a source token's text MUST use format_replaced(&token, &replacement). Do not print the replacement directly and do not use token("...") for replacement text, because the original token still has trivia and must be marked consumed.
  • Custom formatting MUST be carried by a small struct implementing Format<Context>. Do not use free functions or stored closure values to carry formatter state or layout invariants. Use format_with only for one-off local glue that is immediately written.

Node Rules

Generated node rules implement FormatNodeRule. In fmt_fields:

  • destructure the generated *Fields type explicitly;
  • format source tokens through their typed accessors;
  • use _ rather than .. only when the field is consumed elsewhere in the same formatting path or deliberately handled by format_removed / format_replaced; otherwise _ on a node or token field is a dropped-tree bug;
  • preserve every token and comment unless the formatter contract intentionally removes or replaces it;
  • keep layout decisions near the type that owns them.

format_verbatim_* methods preserve a node's source text. Replace verbatim formatting with structured formatting only when tests cover valid, malformed, and commented forms of the node.

Token Rules

Format, replace, or remove every token. Formatter tests panic when a token is not handled, preventing accidental source loss.

Use format_replaced when substituting a token and format_removed when removing one.

Ad-Hoc Formatting

Format a node through node.format() when possible. Its regular rule checks formatter-suppression comments as part of normal formatting.

When a helper formats a node or its tokens outside FormatNodeRule, run the formatter tests. If the suppression-check assertion reports a node, call f.context().comments().mark_suppression_checked(node.syntax()) for that reported node. The assertion shows that the helper bypasses the node's normal suppression check.

IR Composition

Use semantic IR rather than writing whitespace as arbitrary text:

  • space() for required spaces;
  • soft line breaks for optional wrapping;
  • hard line breaks for mandatory breaks;
  • groups to choose flat versus expanded layout;
  • indentation primitives matching the enclosing construct;
  • conditional content tied to the group whose fit decision controls it.

For a distinct formatting concern, use a named type implementing Format. A cluster of free functions that pass &mut Formatter obscures what has already been written and which layout invariants apply.

Represent multi-way layout with an enum selected once. Recomputing layout at several write sites can produce inconsistent output and idempotency failures.

Show full SKILL.md (382 more words)Show less

Comments

Leading and trailing comments are generally handled by formatter infrastructure. Explicitly format dangling comments when the node owns a position to which no child can attach them.

Test comments at each structural boundary affected by the change: before the first child, between children, after the last child, and around empty nodes. Dropping or moving a source comment is data loss.

Tests and Idempotency

Load testing-codegen for snapshot commands and review.

Internal specs should contain the focused source shapes needed to establish canonical output. Where useful, include both already formatted and deliberately unformatted inputs that should converge to the same result.

The formatter test infrastructure reformats error-free, non-range output during the test invocation and fails when the second result differs. IR is diagnostic evidence when output differs; it is not a separate equality contract.

Add internal specs for behavior changes even when a Prettier snapshot changes or disappears. Agreement with one external corpus input does not cover the changed edge case.

Prettier Comparison

Use the repository tool when compatibility is part of the requirement:

shell
bun packages/prettier-compare/bin/prettier-compare.js --rebuild -l js 'const value={a:1}'
bun packages/prettier-compare/bin/prettier-compare.js --rebuild -f path/to/file.js

--rebuild rebuilds Biome's WASM bundle and writes build outputs. It is appropriate during implementation, not during a read-only review.

Treat differences as input to design, not automatic bugs. Biome may intentionally differ when its documented behavior or architecture requires it.

Generation and Verification

After changing source in a language formatter crate:

  1. Run the narrowest formatter crate or spec test and review snapshots before accepting them.
  2. Compare against Prettier when compatibility is relevant; retain reviewed intentional divergences.
  3. Run just f and just l before committing.

Review Checklist

  • Every generated field is handled explicitly.
  • Every child node is formatted through its own rule, or an architecture-specific bypass checks f.context().comments().is_suppressed(node.syntax()) before formatting the node body manually.
  • Every source token is formatted, removed with format_removed, or replaced with format_replaced; no source token is silently skipped, bound to _, or recreated as static text.
  • Comments survive in the intended position.
  • Custom formatting is represented by a struct implementing Format<Context> rather than free functions or closure values.
  • Layout is selected once and composed with semantic IR.
  • Error and bogus syntax remains representable without formatter panics.
  • Internal specs cover the changed behavior.
  • Reformatting converges in one test invocation.

References

  • Formatter guide: crates/biome_formatter/CONTRIBUTING.md
  • JavaScript formatter guide: crates/biome_js_formatter/CONTRIBUTING.md
  • Formatter test infrastructure: crates/biome_formatter_test/src/spec.rs
  • Prettier comparison: packages/prettier-compare/README.md

© biomejs, Apache-2.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in .agents/skills/formatter-development of biomejs/biome.

Open the folder on GitHubat commit c870caa

Compare with similar skills

Formatter Development next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Formatter Development compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Formatter Development this skillbiomejs/biome26k—~2.1kAutomated safety check: PassApache-2.0
Setup Pre Commitfossasia/eventyay-interpretation1.6k13 repos~565Automated safety check: PassApache-2.0
Code Qualityredis/RedisInsight8.9k—~1.2kAutomated safety check: PassCustom licence
Flowmark Markdown Formatterjlevy/repren374—~631Automated safety check: PassMIT
Building Glamorous TuisDicklesworthstone/meta_skill205—~3.4kAutomated safety check: PassCustom licence
Electron App Source ExtractorJimLiu/baoyu-skills26k1 repos~2.6kAutomated safety check: PassMIT

Similar skills

  • Setup Pre Commit

    fossasia/eventyay-interpretation

    Set up Husky pre-commit hooks with lint-staged (Prettier), type checking, and tests in the current repo.

    1.6k GitHub starsUsed in 13 repos~565 tokens
    DevelopmentAuto-check passed
  • Code Quality

    redis/RedisInsight

    Official

    Code-quality standards for RedisInsight: TypeScript strictness, naming conventions (camelCase, PascalCase, UPPERSNAKECASE), linting rules, no any without reason, no !important in styles, and…

    8.9k GitHub stars~1.2k tokensUpdated 3 days ago
    DevelopmentAuto-check passed
  • Formats Markdown with the Flowmark auto-formatter for typographic cleanup and semantic line breaks, and helps adopt it across a repository.

    374 GitHub stars~631 tokensUpdated 1 mo ago
    DevelopmentAuto-check passed
  • Building Glamorous Tuis

    Dicklesworthstone/meta_skill

    Build terminal UIs with Charmbracelet (Bubble Tea, Lip Gloss, Gum).

    205 GitHub stars~3.4k tokensUpdated 3 days ago
    DevelopmentAuto-check passed
  • Unpacks an installed Electron app's asar bundle and restores readable source from its JavaScript source maps when one is available.

    26k GitHub starsUsed in 1 repo~2.6k tokens
    DevelopmentAuto-check passed
  • Migrate Oxfmt

    dxos/dxos

    Guide for migrating a project from Prettier or Biome to Oxfmt.

    525 GitHub starsUsed in 3 repos~2.2k tokens
    DevelopmentAuto-check passed

More from biomejs/biome

All 12 skills in this repo
  • Changeset

    biomejs/biome

    Official

    A skill your agent uses when a Biome change may affect users and you must decide whether it needs a changeset, choose the release level, or create and edit .changeset/.md release-note text.

    26k GitHub stars~839 tokensUpdated today
    Auto-check passed
  • Doc Comments

    biomejs/biome

    Official

    A skill your agent uses whenever writing or editing Rust //, ///, or //!

    26k GitHub stars~3k tokensUpdated today
    Auto-check passed
  • Official

    A skill your agent uses when biome migrate eslint must preserve configurable ESLint rule options through source-option models, Biome conversions, typed rule variants, and migration fixtures.

    26k GitHub stars~1.4k tokensUpdated today
    Auto-check passed
  • Official

    A skill your agent uses when creating or modifying Biome lint rules or assists, including analyzer queries, semantic bindings, rule state, code actions, fix safety, options, registration, and…

    26k GitHub stars~1.6k tokensUpdated today
    Auto-check passed
  • Parser Development

    biomejs/biome

    Official

    A skill your agent uses when implementing or modifying Biome parser behavior, including .ungram grammars, lexers, token sources, parse rules, separated lists, error recovery, and parser fixtures.

    26k GitHub stars~1.2k tokensUpdated today
    Auto-check passed
  • Promote Lint Rules

    biomejs/biome

    Official

    A skill your agent uses when promoting one or more Biome lint rules from nursery to stable groups, including promotion plans from GitHub issues, metadata changes, rule renames, generated…

    26k GitHub stars~948 tokensUpdated today
    Auto-check passed

Works with

Categories

Questions about Formatter Development

What does Formatter Development do?

A skill your agent uses whenever implementing or debugging Biome formatter behavior, IR composition, node rules, layout selection, source-comment handling, verbatim formatting, idempotency, internal…. Formatter Development is an agent skill from biomejs/biome, published by the product's own GitHub organization. Use this skill whenever implementing or debugging Biome formatter behavior, IR composition, node rules, layout selection, source-comment handling, verbatim formatting, idempotency, internal specs, or Prettier comparison.

When should I use Formatter Development?

Formatter Development fits situations like: debugging Biome formatter behavior; layout selection; source-comment handling; verbatim formatting.

How do I install Formatter Development in Claude Code?

Run `npx skills add biomejs/biome --skill formatter-development -a claude-code`. Or copy the skill folder (.agents/skills/formatter-development in biomejs/biome) into .claude/skills/formatter-development in your project. Claude Code loads it when a task matches its description.

How do I install Formatter Development in Codex?

Run `npx skills add biomejs/biome --skill formatter-development -a codex`. Or copy the skill folder (.agents/skills/formatter-development in biomejs/biome) into .agents/skills/formatter-development in your project. Codex loads it when a task matches its description.

Can I use Formatter Development in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add biomejs/biome --skill formatter-development -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/formatter-development, .gemini/skills/formatter-development, .github/skills/formatter-development and .opencode/skills/formatter-development in your project.

What does Formatter Development need to run?

Going by SKILL.md and its folder, Formatter Development needs the command-line tools its instructions call (bun and just). Compatibility (from SKILL.md): Designed for coding agents working on the Biome codebase (github.com/biomejs/biome)..

Does Formatter Development access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Formatter Development safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Formatter Development use?

Formatter Development is published under the Apache-2.0 licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Formatter Development use?

About 2.1k tokens (SKILL.md is roughly 8.6k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Formatter Development?

Skills that share tags, products or a category with Formatter Development: Setup Pre Commit (fossasia/eventyay-interpretation, 1.6k stars), Code Quality (redis/RedisInsight, 8.9k stars), Flowmark Markdown Formatter (jlevy/repren, 374 stars) and Building Glamorous Tuis (Dicklesworthstone/meta_skill, 205 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Formatter Development?

biomejs (a GitHub organization, an official publisher) maintains it in biomejs/biome, which has 25,910 GitHub stars. The repository holds 12 skills in this directory. The repository was last updated on October 8, 2026.

Source: biomejs/biome on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.