keypal / rules
Cursor rule206 starsChanged 12 months agoMITView on GitHub
Ultracite Rules - AI-Ready Formatter and Linter
We split this ultracite.mdc into the rules it gives an agent
150 rules. About 0 are common, 123 are distinctive, and 27 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈123
Distinctive · estimate
This author's own choices. Worth a look.
27
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 18
Consider edge cases and error scenarios
- Distinctive: line 19
Follow the rules below strictly
- Very specific: line 25
Don't use accessKey attribute on any HTML element.
- Very specific: line 26
Don't set aria-hidden="true" on focusable elements.
- Distinctive: line 27
Don't add ARIA roles, states, and properties to elements that don't support them.
- Very specific: line 28
Don't use distracting elements like <marquee> or <blink>.
- Very specific: line 29
Only use the scope prop on <th> elements.
- Distinctive: line 30
Don't assign non-interactive ARIA roles to interactive HTML elements.
- Distinctive: line 31
Make sure label elements have text content and are associated with an input.
- Distinctive: line 32
Don't assign interactive ARIA roles to non-interactive HTML elements.
- Very specific: line 33
Don't assign tabIndex to non-interactive HTML elements.
- Very specific: line 34
Don't use positive integers for tabIndex property.
- Distinctive: line 35
Don't include "image", "picture", or "photo" in img alt prop.
- Distinctive: line 36
Don't use explicit role property that's the same as the implicit/default role.
- Very specific: line 38
Always include a title element for SVG elements.
- Distinctive: line 40
Make sure anchors have content that's accessible to screen readers.
- Distinctive: line 43
Make sure ARIA properties are valid for the element's supported roles.
- Very specific: line 44
Always include a type attribute for button elements.
- Very specific: line 47
Always include a lang attribute on the html element.
- Very specific: line 48
Always include a title attribute for iframe elements.
- Distinctive: line 52
Use semantic elements instead of role attributes in JSX.
- Distinctive: line 53
Make sure all anchors are valid and navigable.
- Very specific: line 54
Ensure all ARIA properties (aria-*) are valid.
- Distinctive: line 55
Use valid, non-abstract ARIA roles for elements with ARIA roles.
- Distinctive: line 56
Use valid ARIA state and property values.
- Very specific: line 57
Use valid values for the autocomplete attribute on input elements.
- Very specific: line 58
Use correct ISO language/country codes for the lang attribute.
- Distinctive: line 61
Don't use consecutive spaces in regular expression literals.
- Very specific: line 62
Don't use the arguments object.
- Distinctive: line 63
Don't use primitive type aliases or misleading types.
- Distinctive: line 64
Don't use the comma operator.
- Distinctive: line 65
Don't use empty type parameters in type aliases and interfaces.
- Distinctive: line 66
Don't write functions that exceed a given Cognitive Complexity score.
- Distinctive: line 67
Don't nest describe() blocks too deeply in test files.
- Distinctive: line 68
Don't use unnecessary boolean casts.
- Distinctive: line 69
Don't use unnecessary callbacks with flatMap.
- Distinctive: line 70
Use for...of statements instead of Array.forEach.
- Distinctive: line 71
Don't create classes that only have static members (like a static namespace).
- Distinctive: line 72
Don't use this and super in static contexts.
- Distinctive: line 73
Don't use unnecessary catch clauses.
- Distinctive: line 74
Don't use unnecessary constructors.
- Distinctive: line 75
Don't use unnecessary continue statements.
- Distinctive: line 76
Don't export empty modules that don't change anything.
- Distinctive: line 77
Don't use unnecessary escape sequences in regular expression literals.
- Distinctive: line 78
Don't use unnecessary fragments.
- Distinctive: line 79
Don't use unnecessary labels.
- Distinctive: line 80
Don't use unnecessary nested block statements.
- Distinctive: line 81
Don't rename imports, exports, and destructured assignments to the same name.
- Distinctive: line 82
Don't use unnecessary string or template literal concatenation.
- Distinctive: line 83
Don't use String.raw in template literals when there are no escape sequences.
- Distinctive: line 84
Don't use useless case statements in switch statements.
- Distinctive: line 85
Don't use ternary operators when simpler alternatives exist.
- Very specific: line 86
Don't use useless this aliasing.
- Distinctive: line 87
Don't use any or unknown as type constraints.
- Distinctive: line 88
Don't initialize variables to undefined.
- Distinctive: line 89
Don't use the void operators (they're not familiar).
- Distinctive: line 90
Use arrow functions instead of function expressions.
- Distinctive: line 91
Use Date.now() to get milliseconds since the Unix Epoch.
- Distinctive: line 92
Use .flatMap() instead of map().flat() when possible.
- Distinctive: line 93
Use literal property access instead of computed property access.
- Distinctive: line 94
Don't use parseInt() or Number.parseInt() when binary, octal, or hexadecimal literals work.
- Distinctive: line 95
Use concise optional chaining instead of chained logical expressions.
- Distinctive: line 96
Use regular expression literals instead of the RegExp constructor when possible.
- Distinctive: line 97
Don't use number literal object member names that aren't base 10 or use underscore separators.
- Distinctive: line 98
Remove redundant terms from logical expressions.
- Distinctive: line 99
Use while loops instead of for loops when you don't need initializer and update expressions.
- Distinctive: line 100
Don't pass children as props.
- Distinctive: line 101
Don't reassign const variables.
- Distinctive: line 102
Don't use constant expressions in conditions.
- Very specific: line 103
Don't use Math.min and Math.max to clamp values when the result is constant.
- Distinctive: line 104
Don't return a value from a constructor.
- Distinctive: line 105
Don't use empty character classes in regular expression literals.
- Distinctive: line 106
Don't use empty destructuring patterns.
- Distinctive: line 107
Don't call global object properties as functions.
- Distinctive: line 108
Don't declare functions and vars that are accessible outside their block.
- Distinctive: line 109
Make sure builtins are correctly instantiated.
- Distinctive: line 110
Don't use super() incorrectly inside classes.
- Distinctive: line 111
Don't use variables and function parameters before they're declared.
- Distinctive: line 112
Don't use 8 and 9 escape sequences in string literals.
- Distinctive: line 113
Don't use literal numbers that lose precision.
- Distinctive: line 116
Don't use the return value of React.render.
- Distinctive: line 117
Make sure all dependencies are correctly specified in React hooks.
- Distinctive: line 118
Make sure all React hooks are called from the top level of component functions.
- Distinctive: line 119
Don't forget key props in iterators and collection literals.
- Distinctive: line 120
Don't destructure props inside JSX components in Solid projects.
- Distinctive: line 121
Don't define React components inside other components.
- Distinctive: line 122
Don't use event handlers on non-interactive elements.
- Distinctive: line 123
Don't assign to React component props.
- Very specific: line 124
Don't use both children and dangerouslySetInnerHTML props on the same element.
- Distinctive: line 125
Don't use dangerous JSX props.
- Distinctive: line 126
Don't use Array index in keys.
- Distinctive: line 127
Don't insert comments as text nodes.
- Distinctive: line 128
Don't assign JSX properties multiple times.
- Distinctive: line 129
Don't add extra closing tags for components without children.
- Very specific: line 130
Use <>...</> instead of <Fragment>...</Fragment>.
- Distinctive: line 134
Don't assign a value to itself.
- Distinctive: line 135
Don't return a value from a setter.
- Distinctive: line 136
Don't compare expressions that modify string case with non-compliant values.
- Distinctive: line 137
Don't use lexical declarations in switch clauses.
- Distinctive: line 138
Don't use variables that haven't been declared in the document.
- Distinctive: line 139
Don't write unreachable code.
- Distinctive: line 140
Make sure super() is called exactly once on every code path in a class constructor before this is accessed if the class has a superclass.
- Distinctive: line 141
Don't use control flow statements in finally blocks.
- Distinctive: line 142
Don't use optional chaining where undefined values aren't allowed.
- Distinctive: line 143
Don't have unused function parameters.
- Distinctive: line 144
Don't have unused imports.
- Distinctive: line 145
Don't have unused labels.
- Distinctive: line 146
Don't have unused private class members.
- Distinctive: line 147
Don't have unused variables.
- Distinctive: line 148
Make sure void (self-closing) elements don't have children.
- Distinctive: line 149
Don't return a value from a function with the return type 'void'
- Distinctive: line 150
Use isNaN() when checking for NaN.
- Distinctive: line 151
Make sure "for" loop update clauses move the counter in the right direction.
- Distinctive: line 152
Make sure typeof expressions are compared to valid values.
- Distinctive: line 153
Make sure generator functions contain yield.
- Distinctive: line 154
Don't use await inside loops.
- Distinctive: line 155
Don't use bitwise operators.
- Distinctive: line 156
Don't use expressions where the operation doesn't change the value.
- Distinctive: line 157
Make sure Promise-like statements are handled appropriately.
- Distinctive: line 158
Don't use __dirname and __filename in the global scope.
- Distinctive: line 160
Don't use configured elements.
- Distinctive: line 161
Don't hardcode sensitive data like API keys and tokens.
- Distinctive: line 162
Don't let variable declarations shadow variables from outer scopes.
- Distinctive: line 163
Don't use the TypeScript directive @ts-ignore.
- Distinctive: line 165
Don't use useless backreferences in regular expressions that always match empty strings.
- Distinctive: line 166
Don't use unnecessary escapes in string literals.
- Distinctive: line 167
Don't use useless undefined.
- Distinctive: line 168
Make sure getters and setters for the same property are next to each other in class and object definitions.
- Distinctive: line 169
Make sure object literals are declared consistently (defaults to explicit definitions).
- Distinctive: line 170
Use static Response methods instead of new Response() constructor when possible.
- Distinctive: line 171
Make sure switch-case statements are exhaustive.
- Very specific: line 172
Make sure the preconnect attribute is used when using Google Fonts.
- Very specific: line 173
Use Array#{indexOf,lastIndexOf}() instead of Array#{findIndex,findLastIndex}() when looking for the index of an item.
- Distinctive: line 174
Make sure iterable callbacks return consistent values.
- Very specific: line 175
Use with { type: "json" } for JSON module imports.
- Distinctive: line 176
Use numeric separators in numeric literals.
- Very specific: line 177
Use object spread instead of Object.assign() when constructing new objects.
- Very specific: line 178
Always use the radix argument when using parseInt().
- Distinctive: line 179
Make sure JSDoc comment lines start with a single asterisk, except for the first one.
- Very specific: line 181
Don't use spread (...) syntax on accumulators.
- Very specific: line 182
Don't use the delete operator.
- Distinctive: line 183
Don't access namespace imports dynamically.
- Distinctive: line 184
Don't use namespace imports.
- Very specific: line 186
Don't use target="_blank" without rel="noopener".
- Distinctive: line 189
Don't use TypeScript enums.
- Distinctive: line 190
Don't export imported variables.
- Distinctive: line 191
Don't add type annotations to variables, parameters, and class properties that are initialized with literal expressions.
- Distinctive: line 192
Don't use TypeScript namespaces.
- Very specific: line 193
Don't use non-null assertions with the !
- Distinctive: line 194
Don't use parameter properties in class constructors.
≈ “Common” is an estimate: at least 1 in 5 of the 6,350 Cursor rule 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.
Files
---
description: Ultracite Rules - AI-Ready Formatter and Linter
globs: "**/*.{ts,tsx,js,jsx}"
alwaysApply: true
---
# Project Context
Ultracite enforces strict type safety, accessibility standards, and consistent code quality for JavaScript/TypeScript projects using Biome's lightning-fast formatter and linter.
## Key Principles
- Zero configuration required
- Subsecond performance
- Maximum type safety
- AI-friendly code generation
## Before Writing Code
1. Analyze existing patterns in the codebase
2. Consider edge cases and error scenarios
3. Follow the rules below strictly
4. Validate accessibility requirements
## Rules
### Accessibility (a11y)
- Don't use `accessKey` attribute on any HTML element.
- Don't set `aria-hidden="true"` on focusable elements.
- Don't add ARIA roles, states, and properties to elements that don't support them.
- Don't use distracting elements like `<marquee>` or `<blink>`.
- Only use the `scope` prop on `<th>` elements.
- Don't assign non-interactive ARIA roles to interactive HTML elements.
- Make sure label elements have text content and are associated with an input.
- Don't assign interactive ARIA roles to non-interactive HTML elements.
- Don't assign `tabIndex` to non-interactive HTML elements.
- Don't use positive integers for `tabIndex` property.
- Don't include "image", "picture", or "photo" in img alt prop.
- Don't use explicit role property that's the same as the implicit/default role.
- Make static elements with click handlers use a valid role attribute.
- Always include a `title` element for SVG elements.
- Give all elements requiring alt text meaningful information for screen readers.
- Make sure anchors have content that's accessible to screen readers.
- Assign `tabIndex` to non-interactive HTML elements with `aria-activedescendant`.
- Include all required ARIA attributes for elements with ARIA roles.
- Make sure ARIA properties are valid for the element's supported roles.
- Always include a `type` attribute for button elements.
- Make elements with interactive roles and handlers focusable.
- Give heading elements content that's accessible to screen readers (not hidden with `aria-hidden`).
- Always include a `lang` attribute on the html element.
- Always include a `title` attribute for iframe elements.
- Accompany `onClick` with at least one of: `onKeyUp`, `onKeyDown`, or `onKeyPress`.
- Accompany `onMouseOver`/`onMouseOut` with `onFocus`/`onBlur`.
- Include caption tracks for audio and video elements.
- Use semantic elements instead of role attributes in JSX.
- Make sure all anchors are valid and navigable.
- Ensure all ARIA properties (`aria-*`) are valid.
- Use valid, non-abstract ARIA roles for elements with ARIA roles.
- Use valid ARIA state and property values.
- Use valid values for the `autocomplete` attribute on input elements.
- Use correct ISO language/country codes for the `lang` attribute.
### Code Complexity and Quality
- Don't use consecutive spaces in regular expression literals.
- Don't use the `arguments` object.
- Don't use primitive type aliases or misleading types.
- Don't use the comma operator.
- Don't use empty type parameters in type aliases and interfaces.
- Don't write functions that exceed a given Cognitive Complexity score.
- Don't nest describe() blocks too deeply in test files.
- Don't use unnecessary boolean casts.
- Don't use unnecessary callbacks with flatMap.
- Use for...of statements instead of Array.forEach.
- Don't create classes that only have static members (like a static namespace).
- Don't use this and super in static contexts.
- Don't use unnecessary catch clauses.
- Don't use unnecessary constructors.
- Don't use unnecessary continue statements.
- Don't export empty modules that don't change anything.
- Don't use unnecessary escape sequences in regular expression literals.
- Don't use unnecessary fragments.
- Don't use unnecessary labels.
- Don't use unnecessary nested block statements.
- Don't rename imports, exports, and destructured assignments to the same name.
- Don't use unnecessary string or template literal concatenation.
- Don't use String.raw in template literals when there are no escape sequences.
- Don't use useless case statements in switch statements.
- Don't use ternary operators when simpler alternatives exist.
- Don't use useless `this` aliasing.
- Don't use any or unknown as type constraints.
- Don't initialize variables to undefined.
- Don't use the void operators (they're not familiar).
- Use arrow functions instead of function expressions.
- Use Date.now() to get milliseconds since the Unix Epoch.
- Use .flatMap() instead of map().flat() when possible.
- Use literal property access instead of computed property access.
- Don't use parseInt() or Number.parseInt() when binary, octal, or hexadecimal literals work.
- Use concise optional chaining instead of chained logical expressions.
- Use regular expression literals instead of the RegExp constructor when possible.
- Don't use number literal object member names that aren't base 10 or use underscore separators.
- Remove redundant terms from logical expressions.
- Use while loops instead of for loops when you don't need initializer and update expressions.
- Don't pass children as props.
- Don't reassign const variables.
- Don't use constant expressions in conditions.
- Don't use `Math.min` and `Math.max` to clamp values when the result is constant.
- Don't return a value from a constructor.
- Don't use empty character classes in regular expression literals.
- Don't use empty destructuring patterns.
- Don't call global object properties as functions.
- Don't declare functions and vars that are accessible outside their block.
- Make sure builtins are correctly instantiated.
- Don't use super() incorrectly inside classes. Also check that super() is called in classes that extend other constructors.
- Don't use variables and function parameters before they're declared.
- Don't use 8 and 9 escape sequences in string literals.
- Don't use literal numbers that lose precision.
### React and JSX Best Practices
- Don't use the return value of React.render.
- Make sure all dependencies are correctly specified in React hooks.
- Make sure all React hooks are called from the top level of component functions.
- Don't forget key props in iterators and collection literals.
- Don't destructure props inside JSX components in Solid projects.
- Don't define React components inside other components.
- Don't use event handlers on non-interactive elements.
- Don't assign to React component props.
- Don't use both `children` and `dangerouslySetInnerHTML` props on the same element.
- Don't use dangerous JSX props.
- Don't use Array index in keys.
- Don't insert comments as text nodes.
- Don't assign JSX properties multiple times.
- Don't add extra closing tags for components without children.
- Use `<>...</>` instead of `<Fragment>...</Fragment>`.
- Watch out for possible "wrong" semicolons inside JSX elements.
### Correctness and Safety
- Don't assign a value to itself.
- Don't return a value from a setter.
- Don't compare expressions that modify string case with non-compliant values.
- Don't use lexical declarations in switch clauses.
- Don't use variables that haven't been declared in the document.
- Don't write unreachable code.
- Make sure super() is called exactly once on every code path in a class constructor before this is accessed if the class has a superclass.
- Don't use control flow statements in finally blocks.
- Don't use optional chaining where undefined values aren't allowed.
- Don't have unused function parameters.
- Don't have unused imports.
- Don't have unused labels.
- Don't have unused private class members.
- Don't have unused variables.
- Make sure void (self-closing) elements don't have children.
- Don't return a value from a function with the return type 'void'
- Use isNaN() when checking for NaN.
- Make sure "for" loop update clauses move the counter in the right direction.
- Make sure typeof expressions are compared to valid values.
- Make sure generator functions contain yield.
- Don't use await inside loops.
- Don't use bitwise operators.
- Don't use expressions where the operation doesn't change the value.
- Make sure Promise-like statements are handled appropriately.
- Don't use __dirname and __filename in the global scope.
- Prevent import cycles.
- Don't use configured elements.
- Don't hardcode sensitive data like API keys and tokens.
- Don't let variable declarations shadow variables from outer scopes.
- Don't use the TypeScript directive @ts-ignore.
- Prevent duplicate polyfills from Polyfill.io.
- Don't use useless backreferences in regular expressions that always match empty strings.
- Don't use unnecessary escapes in string literals.
- Don't use useless undefined.
- Make sure getters and setters for the same property are next to each other in class and object definitions.
- Make sure object literals are declared consistently (defaults to explicit definitions).
- Use static Response methods instead of new Response() constructor when possible.
- Make sure switch-case statements are exhaustive.
- Make sure the `preconnect` attribute is used when using Google Fonts.
- Use `Array#{indexOf,lastIndexOf}()` instead of `Array#{findIndex,findLastIndex}()` when looking for the index of an item.
- Make sure iterable callbacks return consistent values.
- Use `with { type: "json" }` for JSON module imports.
- Use numeric separators in numeric literals.
- Use object spread instead of `Object.assign()` when constructing new objects.
- Always use the radix argument when using `parseInt()`.
- Make sure JSDoc comment lines start with a single asterisk, except for the first one.
- Include a description parameter for `Symbol()`.
- Don't use spread (`...`) syntax on accumulators.
- Don't use the `delete` operator.
- Don't access namespace imports dynamically.
- Don't use namespace imports.
- Declare regex literals at the top level.
- Don't use `target="_blank"` without `rel="noopener"`.
### TypeScript Best Practices
- Don't use TypeScript enums.
- Don't export imported variables.
- Don't add type annotations to variables, parameters, and class properties that are initialized with literal expressions.
- Don't use TypeScript namespaces.
- Don't use non-null assertions with the `!` postfix operator.
- Don't use parameter properties in class constructors.
- Don't use user-defined types.
- Use `as const` instead of literal types and type annotations.
- Use either `T[]` or `Array<T>` consistently.
- Initialize each enum member value explicitly.
- Use `export type` for types.
- Use `import type` for types.
- Make sure all enum members are literal values.
- Don't use TypeScript const enum.
- Don't declare empty interfaces.
- Don't let variables evolve into any type through reassignments.
- Don't use the any type.
- Don't misuse the non-null assertion operator (!) in TypeScript files.
- Don't use implicit any type on variable declarations.
- Don't merge interfaces and classes unsafely.
- Don't use overload signatures that aren't next to each other.
- Use the namespace keyword instead of the module keyword to declare TypeScript namespaces.
### Style and Consistency
- Don't use global `eval()`.
- Don't use callbacks in asynchronous tests and hooks.
- Don't use negation in `if` statements that have `else` clauses.
- Don't use nested ternary expressions.
- Don't reassign function parameters.
- This rule lets you specify global variable names you don't want to use in your application.
- Don't use specified modules when loaded by import or require.
- Don't use constants whose value is the upper-case version of their name.
- Use `String.slice()` instead of `String.substr()` and `String.substring()`.
- Don't use template literals if you don't need interpolation or special-character handling.
- Don't use `else` blocks when the `if` block breaks early.
- Don't use yoda expressions.
- Don't use Array constructors.
- Use `at()` instead of integer index access.
- Follow curly brace conventions.
- Use `else if` instead of nested `if` statements in `else` clauses.
- Use single `if` statements instead of nested `if` clauses.
- Use `new` for all builtins except `String`, `Number`, and `Boolean`.
- Use consistent accessibility modifiers on class properties and methods.
- Use `const` declarations for variables that are only assigned once.
- Put default function parameters and optional function parameters last.
- Include a `default` clause in switch statements.
- Use the `**` operator instead of `Math.pow`.
- Use `for-of` loops when you need the index to extract an item from the iterated array.
- Use `node:assert/strict` over `node:assert`.
- Use the `node:` protocol for Node.js builtin modules.
- Use Number properties instead of global ones.
- Use assignment operator shorthand where possible.
- Use function types instead of object types with call signatures.
- Use template literals over string concatenation.
- Use `new` when throwing an error.
- Don't throw non-Error values.
- Use `String.trimStart()` and `String.trimEnd()` over `String.trimLeft()` and `String.trimRight()`.
- Use standard constants instead of approximated literals.
- Don't assign values in expressions.
- Don't use async functions as Promise executors.
- Don't reassign exceptions in catch clauses.
- Don't reassign class members.
- Don't compare against -0.
- Don't use labeled statements that aren't loops.
- Don't use void type outside of generic or return types.
- Don't use console.
- Don't use control characters and escape sequences that match control characters in regular expression literals.
- Don't use debugger.
- Don't assign directly to document.cookie.
- Use `===` and `!==`.
- Don't use duplicate case labels.
- Don't use duplicate class members.
- Don't use duplicate conditions in if-else-if chains.
- Don't use two keys with the same name inside objects.
- Don't use duplicate function parameter names.
- Don't have duplicate hooks in describe blocks.
- Don't use empty block statements and static blocks.
- Don't let switch clauses fall through.
- Don't reassign function declarations.
- Don't allow assignments to native objects and read-only global variables.
- Use Number.isFinite instead of global isFinite.
- Use Number.isNaN instead of global isNaN.
- Don't assign to imported bindings.
- Don't use irregular whitespace characters.
- Don't use labels that share a name with a variable.
- Don't use characters made with multiple code points in character class syntax.
- Make sure to use new and constructor properly.
- Don't use shorthand assign when the variable appears on both sides.
- Don't use octal escape sequences in string literals.
- Don't use Object.prototype builtins directly.
- Don't redeclare variables, functions, classes, and types in the same scope.
- Don't have redundant "use strict".
- Don't compare things where both sides are exactly the same.
- Don't let identifiers shadow restricted names.
- Don't use sparse arrays (arrays with holes).
- Don't use template literal placeholder syntax in regular strings.
- Don't use the then property.
- Don't use unsafe negation.
- Don't use var.
- Don't use with statements in non-strict contexts.
- Make sure async functions actually use await.
- Make sure default clauses in switch statements come last.
- Make sure to pass a message value when creating a built-in error.
- Make sure get methods always return a value.
- Use a recommended display strategy with Google Fonts.
- Make sure for-in loops include an if statement.
- Use Array.isArray() instead of instanceof Array.
- Make sure to use the digits argument with Number#toFixed().
- Make sure to use the "use strict" directive in script files.
### Next.js Specific Rules
- Don't use `<img>` elements in Next.js projects.
- Don't use `<head>` elements in Next.js projects.
- Don't import next/document outside of pages/_document.jsx in Next.js projects.
- Don't use the next/head module in pages/_document.js on Next.js projects.
### Testing Best Practices
- Don't use export or module.exports in test files.
- Don't use focused tests.
- Make sure the assertion function, like expect, is placed inside an it() function call.
- Don't use disabled tests.
## Common Tasks
- `npx ultracite init` - Initialize Ultracite in your project
- `npx ultracite fix` - Format and fix code automatically
- `npx ultracite check` - Check for issues without fixing
## Example: Error Handling
```typescript
// ✅ Good: Comprehensive error handling
try {
const result = await fetchData();
return { success: true, data: result };
} catch (error) {
console.error('API call failed:', error);
return { success: false, error: error.message };
}
// ❌ Bad: Swallowing errors
try {
return await fetchData();
} catch (e) {
console.log(e);
}
```Other versions14 projects use a version of this.
Word for word · 14
- vercel/ai-chatbot★ 21k100% same
- vercel/chatbot★ 21k100% same
- vercel/components.build★ 793100% same
- robotostudio/turbo-start-sanity★ 183100% same
- TheOrcDev/youtube-to-blog★ 180100% same
- vercel-labs/vectr★ 112100% same
- osadavc/tanchat★ 104100% same
- unstackedapps/opensuitemcp★ 31100% same
- ohansFavour/react-best-practices-agent★ 4100% same
- robotostudio/turbo-start-aisle★ 1100% same
4 more not listed
Edited · 0
None found.
Wrote their own version · 0
None found.
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.
Where files are headingNew Cursor rule files have more rules about planning and tracking tasks, and fewer about code style.
Of the Cursor rule files we read, the 3,978 first seen in the last six months, against the older ones: the kind of rule that gained most share, and the kind that lost most. About files like this in general, not this one, and an estimate, since a kind is a pattern in the words.
In this repository2 other files it gives its agents.
- .claude/CLAUDE.mdCLAUDE.md
- .cursor/rules/use-bun-instead-of-node-vite-npm-pnpm.mdcCursor rule
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
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.

