agentleFS
OpenCut-appOpenCut-app/OpenCut/.github/copilot-instructions.md

OpenCut

Copilot instructions93k starsChanged 7 months agoMITView on GitHub

Ultracite enforces strict type safety, accessibility standards, and consistent code quality for JavaScript/TypeScript projects using Biome's lightning-fast formatter and linter.

We split this copilot-instructions.md into the rules it gives an agent

150 rules. About 1 is common, 122 are distinctive, and 27 are very specific to this project.

  • ≈1

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈122

    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. Common:

    Consider edge cases and error scenarios

    line 19
  2. Distinctive:

    Follow the rules below strictly

    line 20
  3. Very specific:

    Don't use accessKey attribute on any HTML element.

    line 27
  4. Very specific:

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

    line 28
  5. Distinctive:

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

    line 29
  6. Very specific:

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

    line 30
  7. Very specific:

    Only use the scope prop on <th> elements.

    line 31
  8. Distinctive:

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

    line 32
  9. Distinctive:

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

    line 33
  10. Distinctive:

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

    line 34
  11. Very specific:

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

    line 35
  12. Very specific:

    Don't use positive integers for tabIndex property.

    line 36
  13. Distinctive:

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

    line 37
  14. Distinctive:

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

    line 38
  15. Very specific:

    Always include a title element for SVG elements.

    line 40
  16. Distinctive:

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

    line 42
  17. Distinctive:

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

    line 45
  18. Very specific:

    Always include a type attribute for button elements.

    line 46
  19. Very specific:

    Always include a lang attribute on the html element.

    line 49
  20. Very specific:

    Always include a title attribute for iframe elements.

    line 50
  21. Distinctive:

    Use semantic elements instead of role attributes in JSX.

    line 54
  22. Distinctive:

    Make sure all anchors are valid and navigable.

    line 55
  23. Very specific:

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

    line 56
  24. Distinctive:

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

    line 57
  25. Distinctive:

    Use valid ARIA state and property values.

    line 58
  26. Very specific:

    Use valid values for the autocomplete attribute on input elements.

    line 59
  27. Very specific:

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

    line 60
  28. Distinctive:

    Don't use consecutive spaces in regular expression literals.

    line 64
  29. Very specific:

    Don't use the arguments object.

    line 65
  30. Distinctive:

    Don't use primitive type aliases or misleading types.

    line 66
  31. Distinctive:

    Don't use the comma operator.

    line 67
  32. Distinctive:

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

    line 68
  33. Distinctive:

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

    line 69
  34. Distinctive:

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

    line 70
  35. Distinctive:

    Don't use unnecessary boolean casts.

    line 71
  36. Distinctive:

    Don't use unnecessary callbacks with flatMap.

    line 72
  37. Distinctive:

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

    line 73
  38. Distinctive:

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

    line 74
  39. Distinctive:

    Don't use this and super in static contexts.

    line 75
  40. Distinctive:

    Don't use unnecessary catch clauses.

    line 76
  41. Distinctive:

    Don't use unnecessary constructors.

    line 77
  42. Distinctive:

    Don't use unnecessary continue statements.

    line 78
  43. Distinctive:

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

    line 79
  44. Distinctive:

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

    line 80
  45. Distinctive:

    Don't use unnecessary fragments.

    line 81
  46. Distinctive:

    Don't use unnecessary labels.

    line 82
  47. Distinctive:

    Don't use unnecessary nested block statements.

    line 83
  48. Distinctive:

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

    line 84
  49. Distinctive:

    Don't use unnecessary string or template literal concatenation.

    line 85
  50. Distinctive:

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

    line 86
  51. Distinctive:

    Don't use useless case statements in switch statements.

    line 87
  52. Distinctive:

    Don't use ternary operators when simpler alternatives exist.

    line 88
  53. Very specific:

    Don't use useless this aliasing.

    line 89
  54. Distinctive:

    Don't use any or unknown as type constraints.

    line 90
  55. Distinctive:

    Don't initialize variables to undefined.

    line 91
  56. Distinctive:

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

    line 92
  57. Distinctive:

    Use arrow functions instead of function expressions.

    line 93
  58. Distinctive:

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

    line 94
  59. Distinctive:

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

    line 95
  60. Distinctive:

    Use literal property access instead of computed property access.

    line 96
  61. Distinctive:

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

    line 97
  62. Distinctive:

    Use concise optional chaining instead of chained logical expressions.

    line 98
  63. Distinctive:

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

    line 99
  64. Distinctive:

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

    line 100
  65. Distinctive:

    Remove redundant terms from logical expressions.

    line 101
  66. Distinctive:

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

    line 102
  67. Distinctive:

    Don't pass children as props.

    line 103
  68. Distinctive:

    Don't reassign const variables.

    line 104
  69. Distinctive:

    Don't use constant expressions in conditions.

    line 105
  70. Very specific:

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

    line 106
  71. Distinctive:

    Don't return a value from a constructor.

    line 107
  72. Distinctive:

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

    line 108
  73. Distinctive:

    Don't use empty destructuring patterns.

    line 109
  74. Distinctive:

    Don't call global object properties as functions.

    line 110
  75. Distinctive:

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

    line 111
  76. Distinctive:

    Make sure builtins are correctly instantiated.

    line 112
  77. Distinctive:

    Don't use super() incorrectly inside classes.

    line 113
  78. Distinctive:

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

    line 114
  79. Distinctive:

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

    line 115
  80. Distinctive:

    Don't use literal numbers that lose precision.

    line 116
  81. Distinctive:

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

    line 120
  82. Distinctive:

    Make sure all dependencies are correctly specified in React hooks.

    line 121
  83. Distinctive:

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

    line 122
  84. Distinctive:

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

    line 123
  85. Distinctive:

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

    line 124
  86. Distinctive:

    Don't define React components inside other components.

    line 125
  87. Distinctive:

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

    line 126
  88. Distinctive:

    Don't assign to React component props.

    line 127
  89. Very specific:

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

    line 128
  90. Distinctive:

    Don't use dangerous JSX props.

    line 129
  91. Distinctive:

    Don't use Array index in keys.

    line 130
  92. Distinctive:

    Don't insert comments as text nodes.

    line 131
  93. Distinctive:

    Don't assign JSX properties multiple times.

    line 132
  94. Distinctive:

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

    line 133
  95. Very specific:

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

    line 134
  96. Distinctive:

    Don't assign a value to itself.

    line 139
  97. Distinctive:

    Don't return a value from a setter.

    line 140
  98. Distinctive:

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

    line 141
  99. Distinctive:

    Don't use lexical declarations in switch clauses.

    line 142
  100. Distinctive:

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

    line 143
  101. Distinctive:

    Don't write unreachable code.

    line 144
  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 145
  103. Distinctive:

    Don't use control flow statements in finally blocks.

    line 146
  104. Distinctive:

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

    line 147
  105. Distinctive:

    Don't have unused function parameters.

    line 148
  106. Distinctive:

    Don't have unused imports.

    line 149
  107. Distinctive:

    Don't have unused labels.

    line 150
  108. Distinctive:

    Don't have unused private class members.

    line 151
  109. Distinctive:

    Don't have unused variables.

    line 152
  110. Distinctive:

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

    line 153
  111. Distinctive:

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

    line 154
  112. Distinctive:

    Use isNaN() when checking for NaN.

    line 155
  113. Distinctive:

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

    line 156
  114. Distinctive:

    Make sure typeof expressions are compared to valid values.

    line 157
  115. Distinctive:

    Make sure generator functions contain yield.

    line 158
  116. Distinctive:

    Don't use await inside loops.

    line 159
  117. Distinctive:

    Don't use bitwise operators.

    line 160
  118. Distinctive:

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

    line 161
  119. Distinctive:

    Make sure Promise-like statements are handled appropriately.

    line 162
  120. Distinctive:

    Don't use dirname and filename in the global scope.

    line 163
  121. Distinctive:

    Don't use configured elements.

    line 165
  122. Distinctive:

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

    line 166
  123. Distinctive:

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

    line 167
  124. Distinctive:

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

    line 168
  125. Distinctive:

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

    line 170
  126. Distinctive:

    Don't use unnecessary escapes in string literals.

    line 171
  127. Distinctive:

    Don't use useless undefined.

    line 172
  128. Distinctive:

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

    line 173
  129. Distinctive:

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

    line 174
  130. Distinctive:

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

    line 175
  131. Distinctive:

    Make sure switch-case statements are exhaustive.

    line 176
  132. Very specific:

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

    line 177
  133. Very specific:

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

    line 178
  134. Distinctive:

    Make sure iterable callbacks return consistent values.

    line 179
  135. Very specific:

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

    line 180
  136. Distinctive:

    Use numeric separators in numeric literals.

    line 181
  137. Very specific:

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

    line 182
  138. Very specific:

    Always use the radix argument when using parseInt().

    line 183
  139. Distinctive:

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

    line 184
  140. Very specific:

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

    line 186
  141. Very specific:

    Don't use the delete operator.

    line 187
  142. Distinctive:

    Don't access namespace imports dynamically.

    line 188
  143. Distinctive:

    Don't use namespace imports.

    line 189
  144. Very specific:

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

    line 191
  145. Distinctive:

    Don't use TypeScript enums.

    line 195
  146. Distinctive:

    Don't export imported variables.

    line 196
  147. Distinctive:

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

    line 197
  148. Distinctive:

    Don't use TypeScript namespaces.

    line 198
  149. Very specific:

    Don't use non-null assertions with the !

    line 199
  150. Distinctive:

    Don't use parameter properties in class constructors.

    line 200

≈ “Common” is an estimate: at least 1 in 5 of the 3,669 Copilot instructions 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
copilot-instructions.md

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 format - Format and fix code automatically
  • npx ultracite lint - Check for issues without fixing

Example: Error Handling

// ✅ 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)

Trending

Less talk lately.about the whole repository

Dec 2025: 0 mentionsJan 2026: 2 mentionsFeb 2026: 0 mentionsMar 2026: 3 mentionsApr 2026: 3 mentionsMay 2026: 3 mentionsJun 2026: 6 mentionsJul 2026: 29 mentionsAug 2026: 19 mentionsSep 2026: 3 mentionsOct 2026: 6 mentionsNov 2026: 0 mentions
Dec 2025Jun 2026Nov 2026
Mentions a month of the OpenCut-app/OpenCut repository that our weekly crawl found. There is no adoption data for this file yet.

Who's talking about OpenCut-app/OpenCut

The biggest 5 of 103 mentions linking to the repository that our crawl found. Each line is their own headline.

See all 103

Talked about on Bluesky, YouTube, GitHub, the web and Hacker News (103 times).

On Bluesky · 37

32 more on Bluesky

On YouTube · 25

20 more on YouTube

On GitHub · 21

16 more on GitHub

On the web · 16

11 more on the web

On Hacker News · 4

  • Where files are headingNew Copilot instructions files have more rules about branches and pull requests, and fewer about code style.

    Of the Copilot instructions files we read, the 2,297 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.

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.