Biome Complete Toolchain
Complete Biome toolchain guidance for real repository workflows. Use when users ask to configure biome.json, run lint or format commands, migrate from ESLint or Prettier, tune rule severity, fix formatter drift, or replace mixed ESLint+Prettier pipelines with Biome-only workflows.
npx skills add github:pantheon-org/tekhne --skill development--biome-completeWhen to Use
Use this skill when the request includes:
- “set up Biome”
- “configure biome.json”
- “migrate from ESLint” or “migrate from Prettier”
- “fix lint and format drift”
- “run Biome in CI”
- “tune rule severity” or add a targeted suppression
When Not to Use
- The user asks for ESLint-only or Prettier-only solutions.
- The work is about a language or file type Biome does not support.
- The request concerns type checking or test running rather than linting and formatting.
Principles
- Use one source of truth for linting and formatting.
- Prefer deterministic commands and verifiable output.
- Keep SKILL.md short; move deep details to
references/.
Deterministic Workflow
- Confirm scope: migration, config, lint, format, or CI.
- Initialize config if missing:
bunx @biomejs/biome init. - Run checks and capture results:
bunx @biomejs/biome check ..- Verify: Confirm diagnostics are printed. If command fails, check Node.js version (≥14) and file permissions.
- Apply safe autofixes:
bunx @biomejs/biome check . --write.- Verify: Re-run
biome check .and confirm reduced error count. If errors persist, review unsupported rules or migration conflicts inreferences/migration-eslint-prettier.md.
- Verify: Re-run
- Add targeted suppressions only when justified.
- Verify commands pass in local and CI contexts:
bunx @biomejs/biome check . --error-on-warnings.- Verify: Exit code 0 indicates success. If non-zero, review remaining diagnostics and address or document exceptions.
Error Recovery: If biome check fails after migration, isolate conflicting rules by temporarily disabling rule groups in biome.json linter section, then re-enable one group at a time to identify the source.
Quick Commands
Initialize
bunx @biomejs/biome init
Expected result: biome.json exists.
Check repository
bunx @biomejs/biome check .
Expected result: diagnostics printed with file paths.
Apply safe fixes
bunx @biomejs/biome check . --write
Expected result: fixable issues are rewritten.
Format files
bunx @biomejs/biome format . --write
Expected result: formatting is normalized.
Check one file
bunx @biomejs/biome check src/index.ts
Expected result: file-level diagnostics only.
Run in CI
bunx @biomejs/biome check . --error-on-warnings
Expected result: non-zero exit when warnings or errors exist.
Anti-Patterns
NEVER run Biome and ESLint on the same files
WHY: Competing rules create contradictory output and noisy reviews.
BAD: ESLint and Biome both lint src/**/*.ts.
GOOD: Route TS linting and formatting through Biome only.
Consequence: Duplicate diagnostics and unstable CI outcomes.
NEVER run Prettier and Biome formatter on the same files
WHY: Different formatting models cause churn in every commit.
BAD: prettier --write . and biome format . --write in the same pipeline.
GOOD: Keep only biome format . --write for supported files.
Consequence: Constant formatting diffs and merge friction.
NEVER skip biome.json customization after init
WHY: Defaults may not match repository conventions.
BAD: Commit default config without reviewing formatter/linter settings.
GOOD: Define formatter width, linter domains, and VCS ignores explicitly.
Consequence: Inconsistent style and avoidable lint regressions.
NEVER blanket-ignore diagnostics to get green CI
WHY: Broad suppressions hide real defects and debt.
BAD: Disable full rule groups without rationale.
GOOD: Add narrow suppressions with a reason and follow-up ticket.
Consequence: Quality silently degrades over time.
NEVER leave ESLint or Prettier wired in after migrating
WHY: leftover scripts and dev dependencies keep two sources of truth alive and invite the conflicts the migration was meant to remove.
BAD: package.json still has eslint and prettier scripts and packages beside the new Biome scripts.
GOOD: remove the old scripts and dev dependencies and record the removal in the migration notes.
NEVER run the CI check without --error-on-warnings
WHY: without the flag, warnings pass silently and the CI result no longer matches the strict local expectation.
BAD: bunx @biomejs/biome check . as the CI step.
GOOD: bunx @biomejs/biome check . --error-on-warnings.
NEVER add a suppression without a reason
WHY: an unexplained suppression cannot be reviewed or retired, so it becomes permanent debt.
BAD: a bare ignore comment with no explanation.
GOOD: an inline biome-ignore comment naming the rule, the reason and the follow-up ticket.
NEVER re-enable every rule group at once when isolating a failure
WHY: enabling all groups together hides which one conflicts, so the source of the failure is never found.
BAD: disable the whole linter, then switch everything back on in one step.
GOOD: disable rule groups in the linter section, then re-enable one group at a time until the failure returns.
NEVER declare success without re-running the check
WHY: a fix that was never verified may leave errors behind, and an unverified exit code says nothing about CI.
BAD: applying --write and reporting the repository clean.
GOOD: re-run biome check ., confirm the error count dropped, and confirm exit code 0 with --error-on-warnings.
References
| Topic | Reference | When to Use |
|---|---|---|
| Configuration | references/config-biome-json.md | Full biome.json schema, formatter width, linter domains and VCS ignore patterns |
| Lint rules | references/linting-rule-categories.md | Rule groups, severity levels and category-level enable or disable patterns |
| Formatter | references/formatter-options.md | Indent style, line width, quote style and language-specific overrides |
| Migration | references/migration-eslint-prettier.md | Step-by-step migration, rule mapping and conflict resolution |
Explicit NEVER/WHY/consequence triplets with side-by-side bad/good examples. Generic warnings score low — concrete failure modes with real impact (security, correctness, performance) score high.
Runtime validation via eval scenarios proving the skill actually changes agent behaviour. Requires evals/ directory, instructions.json, ≥3 scenarios, and ≥80% instruction coverage in summary.json.
Appropriate rigidity for the skill type: strict rules for critical/security skills, balanced steps for process skills, flexible options for tool skills. Mismatched calibration (too rigid or too loose) reduces score.
Expert-only knowledge the AI couldn't derive on its own — domain-specific patterns, production gotchas, decision frameworks, and non-obvious tool behaviour. High scores mean <5% redundancy with what the model already knows.
A clear philosophy plus numbered step-by-step workflows with explicit entry/exit points. Should answer: what is the core principle, how to execute it, and when (and when not) to apply it.
Rich activation keywords and trigger scenarios in the description so the skill fires when needed. Best descriptions read like an exhaustive list of the tasks and concepts that should invoke this skill.
Copy-paste-ready code, complete runnable examples, real file paths and commands. Pseudocode and abstract descriptions score low — concrete, executable content scores high.
SKILL.md as a <100-line navigation hub pointing to focused references/ files. Content should be lazy-loaded on demand, not front-loaded. Includes actionable 'When to Use' conditions per reference.
Proper frontmatter, single-task focus, activation keywords, and cross-harness portability. Skills must work across 40+ agentic harnesses without hardcoded paths or agent-specific references.
Expert-only knowledge the AI couldn't derive on its own — domain-specific patterns, production gotchas, decision frameworks, and non-obvious tool behaviour. High scores mean <5% redundancy with what the model already knows.
A clear philosophy plus numbered step-by-step workflows with explicit entry/exit points. Should answer: what is the core principle, how to execute it, and when (and when not) to apply it.
Explicit NEVER/WHY/consequence triplets with side-by-side bad/good examples. Generic warnings score low — concrete failure modes with real impact (security, correctness, performance) score high.
Proper frontmatter, single-task focus, activation keywords, and cross-harness portability. Skills must work across 40+ agentic harnesses without hardcoded paths or agent-specific references.
SKILL.md as a <100-line navigation hub pointing to focused references/ files. Content should be lazy-loaded on demand, not front-loaded. Includes actionable 'When to Use' conditions per reference.
Appropriate rigidity for the skill type: strict rules for critical/security skills, balanced steps for process skills, flexible options for tool skills. Mismatched calibration (too rigid or too loose) reduces score.
Rich activation keywords and trigger scenarios in the description so the skill fires when needed. Best descriptions read like an exhaustive list of the tasks and concepts that should invoke this skill.
Copy-paste-ready code, complete runnable examples, real file paths and commands. Pseudocode and abstract descriptions score low — concrete, executable content scores high.
No eval scenarios available.
Biome Config (biome.json)
Use this reference when creating or tightening biome.json.
Baseline Config
{
"$schema": "https://biomejs.dev/schemas/1.9.4/schema.json",
"vcs": {
"enabled": true,
"clientKind": "git",
"useIgnoreFile": true
},
"files": {
"ignoreUnknown": true
},
"formatter": {
"enabled": true,
"lineWidth": 100,
"indentStyle": "space",
"indentWidth": 2
},
"linter": {
"enabled": true,
"rules": {
"recommended": true
}
}
}
Verify
bunx @biomejs/biome check .
Notes
- Keep
useIgnoreFileenabled to honor.gitignore. - Tune
lineWidthto repository standards before broad formatting.
Formatter Options
Use this reference when normalizing project formatting with Biome.
Common Formatter Settings
{
"formatter": {
"enabled": true,
"indentStyle": "space",
"indentWidth": 2,
"lineWidth": 100,
"lineEnding": "lf"
},
"javascript": {
"formatter": {
"quoteStyle": "double",
"trailingCommas": "all"
}
}
}
Verify
bunx @biomejs/biome format . --write
bunx @biomejs/biome check .
Migration Note
Run Biome formatter once after removing Prettier from the same files.
Linting Rule Categories
Use this reference when enabling or tuning Biome linter rules.
Workflow
- Start with
recommended: true. - Promote high-value diagnostics to
error. - Downgrade noisy rules only with justification.
- Re-run
checkand confirm signal quality.
Example Rule Overrides
{
"linter": {
"rules": {
"recommended": true,
"suspicious": {
"noExplicitAny": "error"
},
"style": {
"useImportType": "warn"
}
}
}
}
Verify
bunx @biomejs/biome check .
Anti-pattern
- Do not disable full rule groups to silence one warning.
Migration from ESLint and Prettier
Use this reference to move to Biome without rule or formatter conflicts.
Sequence
- Remove ESLint/Prettier CI jobs for files Biome will own.
- Initialize and customize
biome.json. - Run Biome
checkand address high-signal findings. - Run Biome
format --writeonce across the target scope. - Update CI to enforce Biome only for that scope.
Example Command Sequence
bunx @biomejs/biome init
bunx @biomejs/biome check .
bunx @biomejs/biome check . --write
bunx @biomejs/biome format . --write
Guardrails
- Migrate by scope (folder or package) if repository risk is high.
- Keep suppressions local and documented.
- Avoid parallel Biome + Prettier formatting on the same files.