1---2name: biome-linter3description: JavaScript/TypeScript/JSX/CSS linting guidance based on Biome's 394 lint rules. Use when writing, reviewing, or refactoring JS/TS/JSX/CSS code to catch bugs, enforce style consistency, improve accessibility, avoid performance pitfalls, and prevent security vulnerabilities. Covers correctness, suspicious patterns, style, complexity, a11y, performance, and security categories.4---56# Biome Linter — Claude Code Skill78> **Biome** is a fast formatter and linter for JavaScript, TypeScript, JSX, and CSS.9> This skill distills 394 lint rules into actionable do/don't guidance, organized10> by category. Rules marked **recommended** are enabled by default in Biome.1112## When to Use This Skill1314- Writing or reviewing JavaScript, TypeScript, JSX, or CSS code15- Catching bugs before they reach production16- Enforcing consistent code style across a codebase17- Improving accessibility of HTML/JSX output18- Identifying performance anti-patterns19- Preventing common security vulnerabilities2021## Core Workflow22231. **Identify context** — Determine which categories are relevant (e.g., a11y for UI components, performance for data processing, security for user-facing code)242. **Load references** — Load the relevant category reference files (see table below)253. **Apply rules** — Use the do/don't patterns to guide code writing or review264. **Cite rules** — When flagging issues, reference the Biome rule name (e.g., `noAccumulatingSpread`) so developers can configure or look up the rule2728## Reference Guide2930Load detailed do/don't guidance based on context:3132| Category | Reference | Load When |33|----------|-----------|-----------|34| Correctness | `references/correctness.md` | Catching bugs: wrong assignments, unreachable code, broken control flow |35| Suspicious | `references/suspicious.md` | Likely-wrong patterns: typos, dubious comparisons, debug leftovers |36| Style | `references/style.md` | Code style: naming, syntax preferences, idiomatic patterns |37| Complexity | `references/complexity.md` | Simplification: unnecessary wrappers, redundant logic, over-engineering |38| Accessibility | `references/a11y.md` | HTML/JSX a11y: ARIA, semantic elements, keyboard navigation |39| Performance | `references/performance.md` | Performance: O(n^2) patterns, blocking operations, unnecessary work |40| Security | `references/security.md` | Security: eval(), target=_blank, secrets in code |41| Nursery | `references/nursery.md` | Experimental rules under evaluation, not yet recommended |4243## Critical Rules (Always Apply)4445These are the highest-impact rules you should always keep in mind. For the full46set with examples, load the category reference files above.4748### Correctness — Catch Real Bugs4950| Don't | Do | Rule |51|-------|-----|------|52| Reassign `const` variables | Use `let` if reassignment needed | `noConstAssign` |53| Leave variables unused | Remove or prefix with `_` | `noUnusedVariables` |54| Use `==` or `!=` | Use `===` or `!==` | `noDoubleEquals` |55| Write unreachable code after `return` | Remove dead code | `noUnreachable` |56| Call `new` on non-constructors | Only `new` on classes/constructors | `noInvalidNewBuiltin` |57| Return in setters | Setters should not return values | `noSetterReturn` |5859### Suspicious — Probably Wrong6061| Don't | Do | Rule |62|-------|-----|------|63| Use `console.log()` in production | Remove or use proper logging | `noConsole` |64| Compare with `typeof foo === "strnig"` | Use valid type strings | `noInvalidTypeofComparison` |65| Duplicate keys in objects | Use unique keys | `noDuplicateObjectKeys` |66| Use `debugger` statement | Remove before committing | `noDebugger` |67| Reassign function parameters | Copy to local variable | `noAssignInExpressions` |6869### Performance — Avoid Slowdowns7071| Don't | Do | Rule |72|-------|-----|------|73| `[...acc, val]` in `.reduce()` | `acc.push(val); return acc` | `noAccumulatingSpread` |74| `await` inside loops | Collect promises, `await Promise.all()` | `noAwaitInLoops` |75| `delete obj.key` | `obj.key = undefined` or restructure | `noDelete` |7677### Security — Prevent Vulnerabilities7879| Don't | Do | Rule |80|-------|-----|------|81| `eval("code")` | Avoid eval entirely | `noGlobalEval` |82| `<a target="_blank">` | Add `rel="noopener"` | `noBlankTarget` |83| Hardcode API keys/tokens | Use environment variables | `noSecrets` |8485### Accessibility — Include Everyone8687| Don't | Do | Rule |88|-------|-----|------|89| `<div role="button">` | Use `<button>` | `useSemanticElements` |90| `<img>` without `alt` | Always provide `alt` text | `useAltText` |91| `aria-hidden="true"` on focusable elements | Remove from tab order first | `noAriaHiddenOnFocusable` |92| `tabIndex > 0` | Use `tabIndex={0}` or `tabIndex={-1}` | `noPositiveTabindex` |93| Missing `<label>` for inputs | Associate labels with controls | `noLabelWithoutControl` |9495## Constraints9697### MUST DO98- Always reference the specific Biome rule name when flagging issues99- Prioritize recommended rules (enabled by default) over optional ones100- Consider the project's biome.json configuration — some rules may be intentionally disabled101- Load category reference files for detailed examples before reviewing domain-specific code102103### MUST NOT DO104- Flag nursery rules as errors — they are experimental and may change105- Assume all rules apply — check whether the project uses Biome at all106- Override project-specific rule configurations without discussion107- Apply CSS or GraphQL rules when reviewing pure JavaScript/TypeScript
cnbb-design