agentleFS
Postpartum-genushyacinthus29Postpartum-genushyacinthus29/dotnet-skills/skills/dotnet-biome/SKILL.md

dotnet-biome

Skill13 starsChanged 8 months agoMITView on GitHub

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.

  • Installs packages

The file

We split this skill into the rules it gives an agent

9 rules. About 0 are common, 5 are distinctive, and 4 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈5

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 4

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Prefer a repo-local pinned install so CI and developer machines use the same version.

    line 36
  2. Very specific:

    Add repeatable scripts to package.json, for example:

    line 38
  3. Distinctive:

    Keep file ownership explicit:

    line 41
  4. Very specific:

    Start migrations with check and bounded folders before flipping the whole repo to --write.

    line 45
  5. Distinctive:

    Prefer a repo-local pinned install:

    line 53
  6. Very specific:

    Add repeatable commands to AGENTS.md and package.json, then verify with:

    line 57
  7. Distinctive:

    If developers complain that Biome and ESLint disagree, define file ownership instead of running both broadly on the same surface by …

    line 68
  8. Distinctive:

    Update the plan after each iteration.

    line 89
  9. Very specific:

    If a dependency is missing, bootstrap it or return status: not_applicable with a reason.

    line 91

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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.json
  • biome.json or biome.jsonc
  • current ownership across ESLint, Prettier, Stylelint, and import ordering

Workflow

  1. Decide ownership first:
    • Biome as the main formatter and linter
    • Biome only for formatting
    • Biome in coexistence with ESLint for plugin gaps
  2. Prefer a repo-local pinned install so CI and developer machines use the same version.
  3. Generate biome.json only after confirming what the repo wants Biome to own.
  4. Add repeatable scripts to package.json, for example:
    • biome check .
    • biome check . --write
  5. 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
  6. Start migrations with check and bounded folders before flipping the whole repo to --write.
  7. Re-run the frontend build and tests after broad formatting or lint-fix passes.

Bootstrap When Missing

  1. Detect current state:
    • rg --files -g 'package.json' -g 'biome.json*'
    • rg -n '"@biomejs/biome"|"eslint"|"prettier"|"stylelint"' --glob 'package.json' .
  2. Prefer a repo-local pinned install:
    • npm i -D -E @biomejs/biome
  3. Create config deliberately:
    • npx @biomejs/biome init
  4. Add repeatable commands to AGENTS.md and package.json, then verify with:
    • npx @biomejs/biome check .
    • npx @biomejs/biome check . --write
  5. Return status: configured if Biome is now wired with explicit ownership, or status: improved if the existing setup was tightened.
  6. Return status: not_applicable when 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 --write runs can cause large churn; start with bounded folders or changed files first.
  • Generated assets or vendored code should be excluded in biome.json before 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 check commands
  • 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 --write runs

Ralph Loop

  1. Plan: analyze current state, target outcome, constraints, and risks.
  2. Execute one step and produce a concrete delta.
  3. Review the result and capture findings.
  4. Apply fixes in small batches and rerun checks.
  5. Update the plan after each iteration.
  6. Repeat until outcomes are acceptable.
  7. If a dependency is missing, bootstrap it or return status: not_applicable with a reason.

Required Result Format

  • status: complete | clean | improved | configured | not_applicable | blocked
  • plan: concise plan and current step
  • actions_taken: concrete changes made
  • verification: commands, checks, or review evidence
  • remaining: unresolved items or none

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."

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.