dotnet-biome
Biome for Frontend Assets in .NET Repositories
Trigger On
- the repo has
biome.json,@biomejs/biome, or the user asks for a faster all-in-one frontend formatter-linter stack - the repo wants one tool for formatting, linting, and import organization across JS, TS, CSS, JSON, GraphQL, or HTML
- the team is comparing Biome against ESLint plus Prettier or wants to simplify the current stack
Do Not Use For
- repos that rely on ESLint plugins or framework-specific rules Biome does not cover yet
- runtime site audits such as headers, accessibility, and SEO; route that to
dotnet-webhint - cases where a dedicated CSS or HTML tool is still the deliberate owner and no migration is requested
Inputs
- the nearest
AGENTS.md package.jsonbiome.jsonorbiome.jsonc- current ownership across ESLint, Prettier, Stylelint, and import ordering
Workflow
- Decide ownership first:
- Biome as the main formatter and linter
- Biome only for formatting
- Biome in coexistence with ESLint for plugin gaps
- Prefer a repo-local pinned install so CI and developer machines use the same version.
- Generate
biome.jsononly after confirming what the repo wants Biome to own. - Add repeatable scripts to
package.json, for example:biome check .biome check . --write
- Keep file ownership explicit:
- Biome can own formatting, linting, and import sorting
- webhint still owns site-runtime audits
- ESLint may stay for plugin-heavy cases the repo intentionally keeps
- Start migrations with
checkand bounded folders before flipping the whole repo to--write. - Re-run the frontend build and tests after broad formatting or lint-fix passes.
Bootstrap When Missing
- Detect current state:
rg --files -g 'package.json' -g 'biome.json*'rg -n '"@biomejs/biome"|"eslint"|"prettier"|"stylelint"' --glob 'package.json' .
- Prefer a repo-local pinned install:
npm i -D -E @biomejs/biome
- Create config deliberately:
npx @biomejs/biome init
- Add repeatable commands to
AGENTS.mdandpackage.json, then verify with:npx @biomejs/biome check .npx @biomejs/biome check . --write
- Return
status: configuredif Biome is now wired with explicit ownership, orstatus: improvedif the existing setup was tightened. - Return
status: not_applicablewhen the repo intentionally stays on ESLint-centered ownership and no migration or comparison was requested.
Handle Failures
- Missing-rule parity with specialized ESLint plugins is an ownership problem; keep ESLint for those files until the gap is intentionally closed.
- Overly broad
--writeruns can cause large churn; start with bounded folders or changed files first. - Generated assets or vendored code should be excluded in
biome.jsonbefore trusting the signal. - If developers complain that Biome and ESLint disagree, define file ownership instead of running both broadly on the same surface by accident.
Deliver
- explicit Biome ownership and version pinning
- checked-in config and repeatable
checkcommands - a migration or coexistence plan versus ESLint and other frontend tools
Validate
- the chosen ownership model is documented
- CI and local runs use the same Biome version
- the target globs exclude generated and vendored assets
- downstream build or test flows still pass after
--writeruns
Ralph Loop
- Plan: analyze current state, target outcome, constraints, and risks.
- Execute one step and produce a concrete delta.
- Review the result and capture findings.
- Apply fixes in small batches and rerun checks.
- Update the plan after each iteration.
- Repeat until outcomes are acceptable.
- If a dependency is missing, bootstrap it or return
status: not_applicablewith a reason.
Required Result Format
status:complete|clean|improved|configured|not_applicable|blockedplan: concise plan and current stepactions_taken: concrete changes madeverification: commands, checks, or review evidenceremaining: unresolved items ornone
Example Requests
- "Replace Prettier and basic linting with Biome in this repo."
- "Add Biome to the frontend under ClientApp."
- "Explain whether we should keep ESLint after adding Biome."
More from managedcode/dotnet-skills
dotnet
Primary router skill for broad .NET work. Classify the repo by app model and cross-cutting concern first, then switch to the narrowest matching .NET skill instead of staying at a generic layer.
18dotnet-aspnet-core
Build, debug, modernize, or review ASP.NET Core applications with correct hosting, middleware, security, configuration, logging, and deployment patterns on current .NET.
13dotnet-entity-framework-core
Design, tune, or review EF Core data access with proper modeling, migrations, query translation, performance, and lifetime management for modern .NET applications.
12dotnet-code-review
Review .NET changes for bugs, regressions, architectural drift, missing tests, incorrect async or disposal behavior, and platform-specific pitfalls before you approve or merge them.
11dotnet-architecture
Design or review .NET solution architecture across modular monoliths, clean architecture, vertical slices, microservices, DDD, CQRS, and cloud-native boundaries without over-engineering.
11dotnet-signalr
Implement or review SignalR hubs, streaming, reconnection, transport, and real-time delivery patterns in ASP.NET Core applications.
10