---
name: cursor-rules-generator
description: "Generate .cursorrules / .cursor/rules.mdc files that actually teach Cursor your codebase conventions. Scans your codebase and writes a .cursorrules (or modern .cursor/rules/*.mdc) file with the conventions Cursor needs: naming, folder layout, imports, testing, error handling, framework rules. No more 'Cursor keeps using the wrong pattern'."
license: MIT
---

# Cursor Rules Generator

Cursor's AI is only as good as the context it has about *your* codebase. Without explicit rules it guesses at your conventions — and keeps reaching for the wrong import style, the wrong test framework, or a folder layout you abandoned months ago. This skill scans your repo and writes a `.cursorrules` (legacy) or `.cursor/rules/*.mdc` (current Project Rules) file grounded in how your code is actually written, so Cursor stops guessing.

## When to use it

- You just adopted Cursor on an existing project and want it productive on day one.
- Cursor keeps generating code in a style your team doesn't use (default exports vs. named, `axios` vs. `fetch`, class components vs. hooks).
- You're migrating from the deprecated root `.cursorrules` to the newer `.cursor/rules` directory format.
- A new monorepo package needs its own scoped rules separate from the rest.

## How it works

The skill reads representative source files, config (`package.json`, `tsconfig.json`, `eslint`/`prettier` configs, `vitest`/`jest` setup), and folder structure, then infers and documents:

- **Naming & layout** — file casing, component/hook/util locations, barrel-file usage.
- **Imports** — path aliases (e.g. `@/`), import ordering, named vs. default.
- **Framework rules** — React Server vs. Client components, Next.js App Router conventions, data-fetching patterns.
- **Testing** — which runner, where specs live, naming (`*.test.ts` vs. `*.spec.ts`).
- **Error handling** — Result types, custom error classes, logging conventions.

It emits MDC files with proper frontmatter (`description`, `globs`, `alwaysApply`) so rules attach to the right files. `alwaysApply: true` rules load on every request; `globs`-scoped rules activate only when matching files are in context.

## Example

```bash
curl -fsSL --create-dirs -o ~/.claude/skills/cursor-rules-generator/SKILL.md https://claudeskil.com/skills/cursor-rules-generator/SKILL.md

# then, in your project:
"Generate Cursor rules for this repo using the .mdc format"
```

Produces `.cursor/rules/general.mdc`:

```mdc
---
description: Project-wide conventions
globs: ["**/*.ts", "**/*.tsx"]
alwaysApply: true
---
- Use named exports; no default exports except Next.js pages.
- Import internal modules via the `@/` alias, never relative `../../`.
- Co-locate tests as `Component.test.tsx` and run with Vitest.
- Server Components by default; add `"use client"` only when hooks/events are needed.
```

## Tips & gotchas

- Prefer the `.cursor/rules` directory over a single root `.cursorrules` — the latter is deprecated and harder to scope. Multiple focused `.mdc` files beat one giant rule.
- Keep `alwaysApply` rules short. Everything marked always-apply consumes context on *every* prompt; reserve `globs` for the rest.
- In monorepos, place package-specific `.mdc` files inside each package's `.cursor/rules/` rather than cramming everything at the root.
- Regenerate after big refactors — stale rules actively mislead Cursor.

## FAQ

**Does this replace my ESLint/Prettier config?** No. Those enforce style mechanically; this teaches the AI *before* it writes code, reducing churn the linter would otherwise catch.

**Legacy `.cursorrules` or new `.mdc`?** Both are supported. The skill defaults to `.cursor/rules/*.mdc` since Cursor is phasing out the single-file format; ask for `.cursorrules` if you need it.

**Will it overwrite my existing rules?** It reads what you have and merges rather than clobbering, but review the diff before committing.