Dotnet-skills dotnet-biome
Use Biome in .NET repositories that ship Node-based frontend assets and want a fast combined formatter-linter-import organizer for JavaScript, TypeScript, CSS, JSON, GraphQL, or HTML. Use when a repo prefers a modern all-in-one CLI over a larger ESLint plus Prettier style stack.
install
source · Clone the upstream repo
git clone https://github.com/managedcode/dotnet-skills
Claude Code · Install into ~/.claude/skills/
T=$(mktemp -d) && git clone --depth=1 https://github.com/managedcode/dotnet-skills "$T" && mkdir -p ~/.claude/skills && cp -r "$T/catalog/Tools/Biome/skills/dotnet-biome" ~/.claude/skills/managedcode-dotnet-skills-dotnet-biome && rm -rf "$T"
manifest:
catalog/Tools/Biome/skills/dotnet-biome/SKILL.mdsource content
Biome for Frontend Assets in .NET Repositories
Trigger On
- the repo has
,biome.json
, or the user asks for a faster all-in-one frontend formatter-linter stack@biomejs/biome - 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.json
orbiome.jsonbiome.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
only after confirming what the repo wants Biome to own.biome.json - Add repeatable scripts to
, for example:package.jsonbiome 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
and bounded folders before flipping the whole repo tocheck
.--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
andAGENTS.md
, then verify with:package.jsonnpx @biomejs/biome check .npx @biomejs/biome check . --write
- Return
if Biome is now wired with explicit ownership, orstatus: configured
if the existing setup was tightened.status: improved - Return
when the repo intentionally stays on ESLint-centered ownership and no migration or comparison was requested.status: not_applicable
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
runs can cause large churn; start with bounded folders or changed files first.--write - Generated assets or vendored code should be excluded in
before trusting the signal.biome.json - 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
commandscheck - 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
runs--write
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
with a reason.status: not_applicable
Required Result Format
:status
|complete
|clean
|improved
|configured
|not_applicableblocked
: concise plan and current stepplan
: concrete changes madeactions_taken
: commands, checks, or review evidenceverification
: unresolved items orremainingnone
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."