Cursor Rules: Set It Once

You type "use TypeScript, not JavaScript" into Cursor for the fifth time this week. You explain your team's Tailwind conventions again. Every one of those corrections evaporates the moment the chat ends, because a prompt is not memory — it's a one-time instruction. Cursor Rules fix that permanently.

Why the AI keeps forgetting

A large language model has no persistent state between conversations. Unless something is explicitly re-fed into its context window, it starts from zero every time. That's fine for one-off questions, but it's friction for anything repeated — coding standards, architectural conventions, "always write tests," "never touch the migrations folder." Left alone, you become the model's memory, manually re-pasting the same instructions into every new chat.

Cursor Rules exist specifically to close this gap. A rule is a small, persistent instruction that Cursor reads and injects automatically, so the standard lives in the repo instead of in your typing fingers.

Anatomy of a Cursor Rules file

Rules live in a .cursor/rules folder at the root of your project (Cursor also supports a legacy single .cursorrules file, but the folder form lets you split rules by concern). Each rule file has a rule type that controls when it fires:

• Always — applied to every single prompt in the project, no exceptions. Good for hard constraints: "always use TypeScript," "never commit secrets," "match the existing file's import style."
• Auto attached — applied automatically when the files being edited match a glob pattern you set. Good for scoping a rule to a subsystem instead of the whole repo.
• Agent requested — the rule has a description, and the agent decides whether it's relevant to the current task before pulling it in. Good for guidance that only matters sometimes.

Whichever type you use, the mechanism is the same: once the rule is saved, Cursor reads it automatically on the prompts it applies to. You write the standard once; Cursor re-applies it forever.

How to set it up

1. In your project root, create the folder .cursor/rules if it doesn't exist.
2. Add a new rule file inside it (Cursor's UI can generate the scaffold, or hand-write a markdown file).
3. Set the rule type — for a repo-wide standard, choose Always.
4. Write the instruction plainly: "Always use TypeScript and Tailwind. Do not use inline styles. Match existing naming conventions in the file you're editing."
5. Save. Every prompt in the project now carries this instruction automatically.

If you don't want to write rules from scratch, cursor.directory hosts a library of community-written rules for specific stacks and frameworks that you can copy directly into your project.

Where rules pay off

• Onboarding a new teammate to AI-assisted work. The rules file teaches Cursor the team's conventions on day one, instead of everyone learning by trial and error.
• Working in a legacy repo. A rule can tell Cursor which pattern is current so it stops resurrecting deprecated approaches.
• Enforcing a strict style guide. Linters catch syntax; rules catch intent — things a linter can't express.

Pitfalls

• Don't dump your entire style guide into one Always rule. A giant rule burns context window on every prompt, even irrelevant ones. Split concerns into separate files and use Auto attached or Agent requested types.
• Stale rules are worse than no rules. Update the rule file in the same commit as the convention change — otherwise Cursor confidently enforces a standard your team already abandoned.
• Rules describe conventions, not one-off tasks. Use a rule for "always do X," not for a one-time instruction — that still belongs in the chat prompt.