ultracite
Skill4 starsChanged 27 days agoMITView on GitHub
Ultracite is a zero-config linting and formatting preset for JavaScript/TypeScript projects. Use when: (1) Setting up or initializing Ultracite in a project, or migrating its existing lint and format config onto Ultracite (ultracite init), (2) Running linting or formatting commands (check, fix, doctor), (3) Writing or reviewing JS/TS code in a project that uses Ultracite — to follow its code standards, (4) Troubleshooting linting/formatting issues, (5) Upgrading Ultracite or bringing its configuration up to a newer release (ultracite upgrade), (6) User mentions 'ultracite', 'lint', 'format', 'code quality', or 'biome/eslint/oxlint' in a project with Ultracite installed.
- Reads credentials
8 other projects use a version of this, 6 of them edited.
Adopted by
Most recently taken up by
- wigggle-ui/uiedited, first seen Nov 1, 2026
- tylergibbs1/codewardentheir own version, first seen Nov 1, 2026
- dominik1001/caldav-mcpword for word, first seen Nov 1, 2026
- Limatura/tesseraedited, first seen Nov 1, 2026
- c15t/c15tedited, first seen Oct 8, 2026
- haydenbleasel/ultraciteedited, first seen Oct 8, 2026
Used with
Projects with it also use turborepo and vercel-react-best-practices.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
VercelSkillturborepo
Turborepo monorepo build system guidance. Triggers on: turbo.json, task pipelines, dependsOn, caching, remote cache, the "turbo" CLI, --filter, --affected, CI optimization, environment variables, internal packages, monorepo structure/best practices, and boundaries.
Also in 3 projects that use this
VercelSkillvercel-react-best-practices
React and Next.js performance optimization guidelines from Vercel Engineering. This skill should be used when writing, reviewing, or refactoring React/Next.js code to ensure optimal performance patterns. Triggers on tasks involving React components, Next.js pages, data fetching, bundle optimization, or performance improvements.
Also in 3 projects that use this
Other versions8 projects use a version of this.
Word for word · 1
- dominik1001/caldav-mcp★ 109100% same
Edited · 6
- haydenbleasel/ultracite★ 3.4k98% same
- c15t/c15t★ 2k77% same
- wigggle-ui/ui★ 90185% same
- Limatura/tessera★ 8077% same
- tunnckoCore/skills★ 247% same
- escwxyz/skills-re★ 071% same
Wrote their own version · 1
- tylergibbs1/codewarden★ 1same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository8 other files it gives its agents.
- AGENTS.mdAGENTS.md
- deslopSkill
- emil-design-engSkill
- improveSkill
- react-doctorSkill
- docker-authorSkill
- docker-doctorSkill
- improve-dockerSkill
The file
We split this skill into the rules it gives an agent
11 rules. 3 are common, 0 are distinctive, and 8 are very specific to this project.
3
Common
Most of the 7 edited versions we read keep these.
0
Distinctive
This author's own choices. Worth a look.
8
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 12
Check if ultracite is in package.json dependencies or devDependencies.
- Common: line 122
When writing code in a project with Ultracite, follow these standards.
- Very specific: line 128
Type safety: Use explicit types when they improve clarity.
- Very specific: line 130
Modern JavaScript/TypeScript: Prefer const, destructuring, optional chaining, nullish coalescing, template literals, for...of, and concise …
- Very specific: line 132
Async and correctness: Always await promises in async functions.
- Common: line 134
React and accessibility: Use function components, keep hooks top-level with correct deps, avoid nested component definitions, and use …
- Very specific: line 136
Organization, security, performance, and testing: Keep functions focused, prefer early returns, avoid dangerouslySetInnerHTML and eval(), …
- Very specific: line 140
Run bunx ultracite doctor to diagnose.
- Very specific: line 149
Conflicting configs: After moving to Oxlint or Biome, delete leftover .eslintrc.* and .prettierrc.* files.
- Very specific: line 150
Missing dependency: Run bunx ultracite init again or manually add ultracite to devDependencies
- Common: line 151
Rules not applying: Ensure config file extends the correct presets for your framework
“Common” is measured: kept by at least 6 in 10 of the 7 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Ultracite
Zero-config linting and formatting for JS/TS projects. Supports three linter backends: Oxlint + Oxfmt (recommended), Biome, and ESLint + Prettier + Stylelint.
Detecting Ultracite
Check if ultracite is in package.json dependencies or devDependencies. Detect the active linter by looking for (searching upward from the current directory):
biome.json/biome.jsonc→ Biomeeslint.config.*(.mjs,.js,.cjs,.ts,.mts,.cts) → ESLint (with Prettier for formatting)oxlint.config.ts,oxlint.config.mtsor.oxlintrc.json→ Oxlint (withoxfmt.config.tsoroxfmt.config.mtsfor formatting; init writes the.mtsform in a package that isn't an ES module)
CLI Commands
# Check for issues (read-only)
bunx ultracite check
# Auto-fix issues
bunx ultracite fix
# Diagnose setup problems
bunx ultracite doctor
# Initialize in a new project
bunx ultracite initReplace bunx with npx, pnpm exec, or yarn depending on the package manager, so the project's installed Ultracite runs (pnpm dlx and yarn dlx download the latest release instead, and Yarn 1 has no dlx). Only init in a project without Ultracite needs a download runner such as pnpm dlx.
check and fix accept optional file paths: bunx ultracite check src/index.ts. Unknown options are passed through to the underlying linter (e.g. bunx ultracite check --max-warnings 0).
Initialization
bunx ultracite init runs an interactive setup. For non-interactive (CI) use, pass flags:
bunx ultracite init \
--pm bun \
--linter biome \
--editors universal \
--agents claude copilot \
--frameworks react next \
--integrations husky lint-staged \
--yesFlags:
--pm—npm|yarn|pnpm|bun|deno|nub|aube--linter—oxlint(recommended) |biome|eslint--editors—universal(writes.vscode/settings.jsonfor every VS Code-based editor) |vscode|cursor|devin|codebuddy|antigravity|bob|kiro|trae|void|zed--agents— every choice writes the rules toAGENTS.md.universalwrites only that;claude,gemini,aiderandreplitalso add the import, settings or copy that agent needs to read them; IDs likecodex,copilot,cline,ampandcursor-cli(40 agents supported) need nothing more--frameworks—react|next|solid|vue|svelte|qwik|remix|tanstack|angular|astro|nestjs|jest|vitest|cypress|storybook--integrations—husky|lefthook|lint-staged|pre-commit--hooks— Enable auto-fix hooks:claude|codex|copilot|cursor|devin|codebuddy|deepagents|grok--js-plugins— Opt-in Oxlint JS plugins:@shadcn/lint|anti-slop|eslint-plugin-github|eslint-plugin-jsdoc|eslint-plugin-sonarjs|eslint-plugin-tsdoc|oxlint-plugin-react-doctor--type-aware— Enable type-aware linting (ESLint and Biome: extend theirtype-awarepreset; Oxlint: installsoxlint-tsgolintand setstypeAware), and turn onstrictNullChecksin tsconfig files--install-skill— Install the reusable Ultracite skill after setup--skip-install— Skip dependency installation--yes,-y— Take the defaults without prompting (automatic whenCI=trueor there's no terminal); defaults tooxlintwhen--linteris omitted--quiet— Only print warnings and errors
Init creates config that extends Ultracite presets:
// biome.jsonc
{ "extends": ["ultracite/biome/core", "ultracite/biome/react"] }// eslint.config.mjs — arrays of flat configs, spread together
import core from "ultracite/eslint/core";
import react from "ultracite/eslint/react";
export default [...core, ...react];// oxlint.config.ts — imports passed to extends
import { defineConfig } from "oxlint";
import core from "ultracite/oxlint/core";
export default defineConfig({
env: core.env,
extends: [core],
ignorePatterns: core.ignorePatterns,
});Presets available per linter (ultracite/<linter>/<preset>): core, react, next, solid, vue, svelte, qwik, remix, tanstack, angular, astro, nestjs, jest, vitest, cypress, storybook (cypress and storybook only have rules on ESLint; on Oxlint and Biome they're empty). ESLint and Biome also have type-aware, the rules that need type information, and ESLint has a <framework>/type-aware add-on for angular, jest, nestjs, qwik, tanstack and vitest, extended after that framework's preset. Oxlint also has js-plugins (eslint-plugin-github, eslint-plugin-sonarjs and oxlint-plugin-react-doctor run through oxlint's JS plugin support, with next/js-plugins and tanstack/js-plugins adding framework-specific React Doctor rules), anti-slop and shadcn. These are opt-in: init only adds them when picked in its prompt or passed with --js-plugins. Oxlint and ESLint also have gdp, for codebases that use gdp-ts authorization proofs (@gdp-ts/core ships the plugin); init never adds it, so extend it by hand after core.
Migrating an Existing Project
Migrating means moving the project's own ESLint, Prettier, Stylelint, Biome or Oxlint configuration onto Ultracite's presets; the project can keep its linter. Run init (it preselects the linter it finds), carry over rules the presets don't cover after Ultracite's presets, and run ultracite fix to format everything in one commit. Then fix what check still reports, or migrate progressively:
- Turn off each failing rule after Ultracite's presets: in
rulesfor Oxlint (ultracite check -f jsonlists them asplugin(rule), writtenplugin/rule), orlinter.rulesandassist.actions.sourcefor Biome (ultracite check --reporter=summary). On ESLint,ultracite check --suppress-allrecords today's errors ineslint-suppressions.jsoninstead. - Turn them back on a few at a time: remove an override (or prune with
ultracite check --prune-suppressions), runultracite fix, fix the rest, one rule per change.
Full steps: https://www.ultracite.ai/docs/migrate.md
Upgrading
npx ultracite@latest upgradeupgrade installs the latest Ultracite (or the release --version 7 names), reinstalls the linter at the versions that release supports, and runs doctor. Major releases also change how the configuration looks; upgrade lists the guides the project still needs, and with --claude or --codex it has that agent CLI apply them.
To apply them yourself, follow each guide that applies, oldest first. Each one says how to tell whether the project needs it:
- references/upgrades/v5.md: Biome 1's config format to Biome 2's
- references/upgrades/v6.md: the single
ultracitepreset toultracite/coreplus framework presets - references/upgrades/v7.md:
ultracite/<preset>toultracite/biome/<preset>, and thelintandformatcommands tocheckandfix - references/upgrades/v8.md: removing
prettier/prettierfrom ESLint and Stylelint configs, the Cypress and Storybook presets, ESLint configs that set type-checked rules, Oxlint'stypeAwareoption,init --yes, and Zed's formatter on ESLint
Code Standards
When writing code in a project with Ultracite, follow these standards. For the full rules reference, see references/code-standards.md.
Key rules at a glance:
Formatting is handled by the project's configured linter/formatter. Respect the repository's existing formatter settings instead of forcing one fixed line width, quote style, or trailing comma policy.
Type safety: Use explicit types when they improve clarity. Prefer unknown over any. Use as const for immutable values and rely on type narrowing over blunt assertions.
Modern JavaScript/TypeScript: Prefer const, destructuring, optional chaining, nullish coalescing, template literals, for...of, and concise arrow functions.
Async and correctness: Always await promises in async functions. Prefer async/await over promise chains. Remove console.log, debugger, and alert from production code.
React and accessibility: Use function components, keep hooks top-level with correct deps, avoid nested component definitions, and use semantic HTML with the right labels, headings, alt text, and keyboard affordances.
Organization, security, performance, and testing: Keep functions focused, prefer early returns, avoid dangerouslySetInnerHTML and eval(), prefer specific imports and top-level regex, and keep tests free of .only and .skip.
Troubleshooting
Run bunx ultracite doctor to diagnose. It checks:
- Linter and formatter installation (Biome; or ESLint + Prettier + Stylelint; or Oxlint + oxfmt)
- Config validity (extends the ultracite presets correctly)
- Ultracite in package.json dependencies
- Conflicting tools when not using the ESLint backend (legacy
.eslintrc.*files,.prettierrc.*/prettier.config.*)
Common fixes:
- Conflicting configs: After moving to Oxlint or Biome, delete leftover
.eslintrc.*and.prettierrc.*files. On ESLint,.eslintrc.*files are inert (ESLint 10 only readseslint.config.*) and.prettierrc.*is the formatter's config, so neither is a conflict - Missing dependency: Run
bunx ultracite initagain or manually addultraciteto devDependencies - Rules not applying: Ensure config file extends the correct presets for your framework
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
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.

