agentleFS
PunGrumpyPunGrumpy/logixlysia/.cursor/rules/ultracite.mdc

logixlysia / rules

Cursor rule275 starsChanged 4 months agoMITView on GitHub

Ultracite Rules - AI-Ready Formatter and Linter

  • 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 4,181 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 repository3 other files it gives its agents.

The file

Show its rules and text

We split this ultracite.mdc into the rules it gives an agent

47 rules. About 0 are common, 25 are distinctive, and 22 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈25

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 22

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Write code that is accessible, performant, type-safe, and maintainable.

    line 23
  2. Distinctive:

    Use explicit types for function parameters and return values when they enhance clarity

    line 27
  3. Very specific:

    Prefer unknown over any when the type is genuinely unknown

    line 28
  4. Very specific:

    Use const assertions (as const) for immutable values and literal types

    line 29
  5. Distinctive:

    Use meaningful variable names instead of magic numbers - extract constants with descriptive names

    line 31
  6. Distinctive:

    Use arrow functions for callbacks and short functions

    line 35
  7. Very specific:

    Prefer for...of loops over .forEach() and indexed for loops

    line 36
  8. Very specific:

    Use optional chaining (?.) and nullish coalescing (??) for safer property access

    line 37
  9. Distinctive:

    Prefer template literals over string concatenation

    line 38
  10. Distinctive:

    Use destructuring for object and array assignments

    line 39
  11. Very specific:

    Use const by default, let only when reassignment is needed, never var

    line 40
  12. Very specific:

    Always await promises in async functions - don't forget to use the return value

    line 44
  13. Very specific:

    Use async/await syntax instead of promise chains for better readability

    line 45
  14. Distinctive:

    Don't use async functions as Promise executors

    line 47
  15. Distinctive:

    Use function components over class components

    line 51
  16. Distinctive:

    Call hooks at the top level only, never conditionally

    line 52
  17. Very specific:

    Use the key prop for elements in iterables (prefer unique IDs over array indices)

    line 54
  18. Distinctive:

    Don't define components inside other components

    line 56
  19. Distinctive:

    Use semantic HTML and ARIA attributes for accessibility:

    line 57
  20. Distinctive:

    Use proper heading hierarchy

    line 59
  21. Distinctive:

    Add labels for form inputs

    line 60
  22. Very specific:

    Use semantic elements (<button>, <nav>, etc.) instead of divs with roles

    line 62
  23. Very specific:

    Remove console.log, debugger, and alert statements from production code

    line 66
  24. Very specific:

    Use try-catch blocks meaningfully - don't catch errors just to rethrow them

    line 68
  25. Distinctive:

    Prefer early returns over nested conditionals for error cases

    line 69
  26. Distinctive:

    Keep functions focused and under reasonable cognitive complexity limits

    line 73
  27. Distinctive:

    Use early returns to reduce nesting

    line 75
  28. Distinctive:

    Prefer simple conditionals over nested ternary operators

    line 76
  29. Very specific:

    Add rel="noopener" when using target="_blank" on links

    line 81
  30. Very specific:

    Avoid dangerouslySetInnerHTML unless absolutely necessary

    line 82
  31. Very specific:

    Don't use eval() or assign directly to document.cookie

    line 83
  32. Distinctive:

    Avoid spread syntax in accumulators within loops

    line 88
  33. Distinctive:

    Use top-level regex literals instead of creating them in loops

    line 89
  34. Distinctive:

    Prefer specific imports over namespace imports

    line 90
  35. Distinctive:

    Avoid barrel files (index files that re-export everything)

    line 91
  36. Very specific:

    Use proper image components (e.g., Next.js <Image>) over <img> tags

    line 92
  37. Very specific:

    Use Next.js <Image> component for images

    line 97
  38. Very specific:

    Use next/head or App Router metadata API for head elements

    line 98
  39. Distinctive:

    Use Server Components for async data fetching instead of async Client Components

    line 99
  40. Very specific:

    Use ref as a prop instead of React.forwardRef

    line 102
  41. Very specific:

    Use class and for attributes (not className or htmlFor)

    line 105
  42. Very specific:

    Write assertions inside it() or test() blocks

    line 111
  43. Distinctive:

    Avoid done callbacks in async tests - use async/await instead

    line 112
  44. Very specific:

    Don't use .only or .skip in committed code

    line 113
  45. Very specific:

    Keep test suites reasonably flat - avoid excessive describe nesting

    line 114
  46. Distinctive:

    Meaningful naming: - Use descriptive names for functions, variables, and types

    line 121
  47. Distinctive:

    Documentation: - Add comments for complex logic, but prefer self-documenting code

    line 125

≈ “Common” is an estimate: at least 1 in 5 of the 6,668 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,json,jsonc,html,vue,svelte,astro,css,yaml,yml,graphql,gql,md,mdx,grit}"
alwaysApply: false
---

# Ultracite Code Standards

This project uses **Ultracite**, a zero-config preset that enforces strict code quality standards through automated formatting and linting.

## Quick Reference

- **Format code**: `bun x ultracite fix`
- **Check for issues**: `bun x ultracite check`
- **Diagnose setup**: `bun x ultracite doctor`

Oxlint + Oxfmt (the underlying engine) provides robust linting and formatting. Most issues are automatically fixable.

---

## Core Principles

Write code that is **accessible, performant, type-safe, and maintainable**. Focus on clarity and explicit intent over brevity.

### Type Safety & Explicitness

- Use explicit types for function parameters and return values when they enhance clarity
- Prefer `unknown` over `any` when the type is genuinely unknown
- Use const assertions (`as const`) for immutable values and literal types
- Leverage TypeScript's type narrowing instead of type assertions
- Use meaningful variable names instead of magic numbers - extract constants with descriptive names

### Modern JavaScript/TypeScript

- Use arrow functions for callbacks and short functions
- Prefer `for...of` loops over `.forEach()` and indexed `for` loops
- Use optional chaining (`?.`) and nullish coalescing (`??`) for safer property access
- Prefer template literals over string concatenation
- Use destructuring for object and array assignments
- Use `const` by default, `let` only when reassignment is needed, never `var`

### Async & Promises

- Always `await` promises in async functions - don't forget to use the return value
- Use `async/await` syntax instead of promise chains for better readability
- Handle errors appropriately in async code with try-catch blocks
- Don't use async functions as Promise executors

### React & JSX

- Use function components over class components
- Call hooks at the top level only, never conditionally
- Specify all dependencies in hook dependency arrays correctly
- Use the `key` prop for elements in iterables (prefer unique IDs over array indices)
- Nest children between opening and closing tags instead of passing as props
- Don't define components inside other components
- Use semantic HTML and ARIA attributes for accessibility:
  - Provide meaningful alt text for images
  - Use proper heading hierarchy
  - Add labels for form inputs
  - Include keyboard event handlers alongside mouse events
  - Use semantic elements (`<button>`, `<nav>`, etc.) instead of divs with roles

### Error Handling & Debugging

- Remove `console.log`, `debugger`, and `alert` statements from production code
- Throw `Error` objects with descriptive messages, not strings or other values
- Use `try-catch` blocks meaningfully - don't catch errors just to rethrow them
- Prefer early returns over nested conditionals for error cases

### Code Organization

- Keep functions focused and under reasonable cognitive complexity limits
- Extract complex conditions into well-named boolean variables
- Use early returns to reduce nesting
- Prefer simple conditionals over nested ternary operators
- Group related code together and separate concerns

### Security

- Add `rel="noopener"` when using `target="_blank"` on links
- Avoid `dangerouslySetInnerHTML` unless absolutely necessary
- Don't use `eval()` or assign directly to `document.cookie`
- Validate and sanitize user input

### Performance

- Avoid spread syntax in accumulators within loops
- Use top-level regex literals instead of creating them in loops
- Prefer specific imports over namespace imports
- Avoid barrel files (index files that re-export everything)
- Use proper image components (e.g., Next.js `<Image>`) over `<img>` tags

### Framework-Specific Guidance

**Next.js:**
- Use Next.js `<Image>` component for images
- Use `next/head` or App Router metadata API for head elements
- Use Server Components for async data fetching instead of async Client Components

**React 19+:**
- Use ref as a prop instead of `React.forwardRef`

**Solid/Svelte/Vue/Qwik:**
- Use `class` and `for` attributes (not `className` or `htmlFor`)

---

## Testing

- Write assertions inside `it()` or `test()` blocks
- Avoid done callbacks in async tests - use async/await instead
- Don't use `.only` or `.skip` in committed code
- Keep test suites reasonably flat - avoid excessive `describe` nesting

## When Oxlint + Oxfmt Can't Help

Oxlint + Oxfmt's linter will catch most issues automatically. Focus your attention on:

1. **Business logic correctness** - Oxlint + Oxfmt can't validate your algorithms
2. **Meaningful naming** - Use descriptive names for functions, variables, and types
3. **Architecture decisions** - Component structure, data flow, and API design
4. **Edge cases** - Handle boundary conditions and error states
5. **User experience** - Accessibility, performance, and usability considerations
6. **Documentation** - Add comments for complex logic, but prefer self-documenting code

---

Most formatting and common issues are automatically fixed by Oxlint + Oxfmt. Run `bun x ultracite fix` before committing to ensure compliance.

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.

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.