agentleFS
izadoesdevizadoesdev/keypal/.cursor/rules/ultracite.mdc

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
  1. Distinctive:

    Consider edge cases and error scenarios

    line 18
  2. Distinctive:

    Follow the rules below strictly

    line 19
  3. Very specific:

    Don't use accessKey attribute on any HTML element.

    line 25
  4. Very specific:

    Don't set aria-hidden="true" on focusable elements.

    line 26
  5. Distinctive:

    Don't add ARIA roles, states, and properties to elements that don't support them.

    line 27
  6. Very specific:

    Don't use distracting elements like <marquee> or <blink>.

    line 28
  7. Very specific:

    Only use the scope prop on <th> elements.

    line 29
  8. Distinctive:

    Don't assign non-interactive ARIA roles to interactive HTML elements.

    line 30
  9. Distinctive:

    Make sure label elements have text content and are associated with an input.

    line 31
  10. Distinctive:

    Don't assign interactive ARIA roles to non-interactive HTML elements.

    line 32
  11. Very specific:

    Don't assign tabIndex to non-interactive HTML elements.

    line 33
  12. Very specific:

    Don't use positive integers for tabIndex property.

    line 34
  13. Distinctive:

    Don't include "image", "picture", or "photo" in img alt prop.

    line 35
  14. Distinctive:

    Don't use explicit role property that's the same as the implicit/default role.

    line 36
  15. Very specific:

    Always include a title element for SVG elements.

    line 38
  16. Distinctive:

    Make sure anchors have content that's accessible to screen readers.

    line 40
  17. Distinctive:

    Make sure ARIA properties are valid for the element's supported roles.

    line 43
  18. Very specific:

    Always include a type attribute for button elements.

    line 44
  19. Very specific:

    Always include a lang attribute on the html element.

    line 47
  20. Very specific:

    Always include a title attribute for iframe elements.

    line 48
  21. Distinctive:

    Use semantic elements instead of role attributes in JSX.

    line 52
  22. Distinctive:

    Make sure all anchors are valid and navigable.

    line 53
  23. Very specific:

    Ensure all ARIA properties (aria-*) are valid.

    line 54
  24. Distinctive:

    Use valid, non-abstract ARIA roles for elements with ARIA roles.

    line 55
  25. Distinctive:

    Use valid ARIA state and property values.

    line 56
  26. Very specific:

    Use valid values for the autocomplete attribute on input elements.

    line 57
  27. Very specific:

    Use correct ISO language/country codes for the lang attribute.

    line 58
  28. Distinctive:

    Don't use consecutive spaces in regular expression literals.

    line 61
  29. Very specific:

    Don't use the arguments object.

    line 62
  30. Distinctive:

    Don't use primitive type aliases or misleading types.

    line 63
  31. Distinctive:

    Don't use the comma operator.

    line 64
  32. Distinctive:

    Don't use empty type parameters in type aliases and interfaces.

    line 65
  33. Distinctive:

    Don't write functions that exceed a given Cognitive Complexity score.

    line 66
  34. Distinctive:

    Don't nest describe() blocks too deeply in test files.

    line 67
  35. Distinctive:

    Don't use unnecessary boolean casts.

    line 68
  36. Distinctive:

    Don't use unnecessary callbacks with flatMap.

    line 69
  37. Distinctive:

    Use for...of statements instead of Array.forEach.

    line 70
  38. Distinctive:

    Don't create classes that only have static members (like a static namespace).

    line 71
  39. Distinctive:

    Don't use this and super in static contexts.

    line 72
  40. Distinctive:

    Don't use unnecessary catch clauses.

    line 73
  41. Distinctive:

    Don't use unnecessary constructors.

    line 74
  42. Distinctive:

    Don't use unnecessary continue statements.

    line 75
  43. Distinctive:

    Don't export empty modules that don't change anything.

    line 76
  44. Distinctive:

    Don't use unnecessary escape sequences in regular expression literals.

    line 77
  45. Distinctive:

    Don't use unnecessary fragments.

    line 78
  46. Distinctive:

    Don't use unnecessary labels.

    line 79
  47. Distinctive:

    Don't use unnecessary nested block statements.

    line 80
  48. Distinctive:

    Don't rename imports, exports, and destructured assignments to the same name.

    line 81
  49. Distinctive:

    Don't use unnecessary string or template literal concatenation.

    line 82
  50. Distinctive:

    Don't use String.raw in template literals when there are no escape sequences.

    line 83
  51. Distinctive:

    Don't use useless case statements in switch statements.

    line 84
  52. Distinctive:

    Don't use ternary operators when simpler alternatives exist.

    line 85
  53. Very specific:

    Don't use useless this aliasing.

    line 86
  54. Distinctive:

    Don't use any or unknown as type constraints.

    line 87
  55. Distinctive:

    Don't initialize variables to undefined.

    line 88
  56. Distinctive:

    Don't use the void operators (they're not familiar).

    line 89
  57. Distinctive:

    Use arrow functions instead of function expressions.

    line 90
  58. Distinctive:

    Use Date.now() to get milliseconds since the Unix Epoch.

    line 91
  59. Distinctive:

    Use .flatMap() instead of map().flat() when possible.

    line 92
  60. Distinctive:

    Use literal property access instead of computed property access.

    line 93
  61. Distinctive:

    Don't use parseInt() or Number.parseInt() when binary, octal, or hexadecimal literals work.

    line 94
  62. Distinctive:

    Use concise optional chaining instead of chained logical expressions.

    line 95
  63. Distinctive:

    Use regular expression literals instead of the RegExp constructor when possible.

    line 96
  64. Distinctive:

    Don't use number literal object member names that aren't base 10 or use underscore separators.

    line 97
  65. Distinctive:

    Remove redundant terms from logical expressions.

    line 98
  66. Distinctive:

    Use while loops instead of for loops when you don't need initializer and update expressions.

    line 99
  67. Distinctive:

    Don't pass children as props.

    line 100
  68. Distinctive:

    Don't reassign const variables.

    line 101
  69. Distinctive:

    Don't use constant expressions in conditions.

    line 102
  70. Very specific:

    Don't use Math.min and Math.max to clamp values when the result is constant.

    line 103
  71. Distinctive:

    Don't return a value from a constructor.

    line 104
  72. Distinctive:

    Don't use empty character classes in regular expression literals.

    line 105
  73. Distinctive:

    Don't use empty destructuring patterns.

    line 106
  74. Distinctive:

    Don't call global object properties as functions.

    line 107
  75. Distinctive:

    Don't declare functions and vars that are accessible outside their block.

    line 108
  76. Distinctive:

    Make sure builtins are correctly instantiated.

    line 109
  77. Distinctive:

    Don't use super() incorrectly inside classes.

    line 110
  78. Distinctive:

    Don't use variables and function parameters before they're declared.

    line 111
  79. Distinctive:

    Don't use 8 and 9 escape sequences in string literals.

    line 112
  80. Distinctive:

    Don't use literal numbers that lose precision.

    line 113
  81. Distinctive:

    Don't use the return value of React.render.

    line 116
  82. Distinctive:

    Make sure all dependencies are correctly specified in React hooks.

    line 117
  83. Distinctive:

    Make sure all React hooks are called from the top level of component functions.

    line 118
  84. Distinctive:

    Don't forget key props in iterators and collection literals.

    line 119
  85. Distinctive:

    Don't destructure props inside JSX components in Solid projects.

    line 120
  86. Distinctive:

    Don't define React components inside other components.

    line 121
  87. Distinctive:

    Don't use event handlers on non-interactive elements.

    line 122
  88. Distinctive:

    Don't assign to React component props.

    line 123
  89. Very specific:

    Don't use both children and dangerouslySetInnerHTML props on the same element.

    line 124
  90. Distinctive:

    Don't use dangerous JSX props.

    line 125
  91. Distinctive:

    Don't use Array index in keys.

    line 126
  92. Distinctive:

    Don't insert comments as text nodes.

    line 127
  93. Distinctive:

    Don't assign JSX properties multiple times.

    line 128
  94. Distinctive:

    Don't add extra closing tags for components without children.

    line 129
  95. Very specific:

    Use <>...</> instead of <Fragment>...</Fragment>.

    line 130
  96. Distinctive:

    Don't assign a value to itself.

    line 134
  97. Distinctive:

    Don't return a value from a setter.

    line 135
  98. Distinctive:

    Don't compare expressions that modify string case with non-compliant values.

    line 136
  99. Distinctive:

    Don't use lexical declarations in switch clauses.

    line 137
  100. Distinctive:

    Don't use variables that haven't been declared in the document.

    line 138
  101. Distinctive:

    Don't write unreachable code.

    line 139
  102. Distinctive:

    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.

    line 140
  103. Distinctive:

    Don't use control flow statements in finally blocks.

    line 141
  104. Distinctive:

    Don't use optional chaining where undefined values aren't allowed.

    line 142
  105. Distinctive:

    Don't have unused function parameters.

    line 143
  106. Distinctive:

    Don't have unused imports.

    line 144
  107. Distinctive:

    Don't have unused labels.

    line 145
  108. Distinctive:

    Don't have unused private class members.

    line 146
  109. Distinctive:

    Don't have unused variables.

    line 147
  110. Distinctive:

    Make sure void (self-closing) elements don't have children.

    line 148
  111. Distinctive:

    Don't return a value from a function with the return type 'void'

    line 149
  112. Distinctive:

    Use isNaN() when checking for NaN.

    line 150
  113. Distinctive:

    Make sure "for" loop update clauses move the counter in the right direction.

    line 151
  114. Distinctive:

    Make sure typeof expressions are compared to valid values.

    line 152
  115. Distinctive:

    Make sure generator functions contain yield.

    line 153
  116. Distinctive:

    Don't use await inside loops.

    line 154
  117. Distinctive:

    Don't use bitwise operators.

    line 155
  118. Distinctive:

    Don't use expressions where the operation doesn't change the value.

    line 156
  119. Distinctive:

    Make sure Promise-like statements are handled appropriately.

    line 157
  120. Distinctive:

    Don't use __dirname and __filename in the global scope.

    line 158
  121. Distinctive:

    Don't use configured elements.

    line 160
  122. Distinctive:

    Don't hardcode sensitive data like API keys and tokens.

    line 161
  123. Distinctive:

    Don't let variable declarations shadow variables from outer scopes.

    line 162
  124. Distinctive:

    Don't use the TypeScript directive @ts-ignore.

    line 163
  125. Distinctive:

    Don't use useless backreferences in regular expressions that always match empty strings.

    line 165
  126. Distinctive:

    Don't use unnecessary escapes in string literals.

    line 166
  127. Distinctive:

    Don't use useless undefined.

    line 167
  128. Distinctive:

    Make sure getters and setters for the same property are next to each other in class and object definitions.

    line 168
  129. Distinctive:

    Make sure object literals are declared consistently (defaults to explicit definitions).

    line 169
  130. Distinctive:

    Use static Response methods instead of new Response() constructor when possible.

    line 170
  131. Distinctive:

    Make sure switch-case statements are exhaustive.

    line 171
  132. Very specific:

    Make sure the preconnect attribute is used when using Google Fonts.

    line 172
  133. Very specific:

    Use Array#{indexOf,lastIndexOf}() instead of Array#{findIndex,findLastIndex}() when looking for the index of an item.

    line 173
  134. Distinctive:

    Make sure iterable callbacks return consistent values.

    line 174
  135. Very specific:

    Use with { type: "json" } for JSON module imports.

    line 175
  136. Distinctive:

    Use numeric separators in numeric literals.

    line 176
  137. Very specific:

    Use object spread instead of Object.assign() when constructing new objects.

    line 177
  138. Very specific:

    Always use the radix argument when using parseInt().

    line 178
  139. Distinctive:

    Make sure JSDoc comment lines start with a single asterisk, except for the first one.

    line 179
  140. Very specific:

    Don't use spread (...) syntax on accumulators.

    line 181
  141. Very specific:

    Don't use the delete operator.

    line 182
  142. Distinctive:

    Don't access namespace imports dynamically.

    line 183
  143. Distinctive:

    Don't use namespace imports.

    line 184
  144. Very specific:

    Don't use target="_blank" without rel="noopener".

    line 186
  145. Distinctive:

    Don't use TypeScript enums.

    line 189
  146. Distinctive:

    Don't export imported variables.

    line 190
  147. Distinctive:

    Don't add type annotations to variables, parameters, and class properties that are initialized with literal expressions.

    line 191
  148. Distinctive:

    Don't use TypeScript namespaces.

    line 192
  149. Very specific:

    Don't use non-null assertions with the !

    line 193
  150. Distinctive:

    Don't use parameter properties in class constructors.

    line 194

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
ultracite.mdc
---
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);
}
```

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.

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.