Cursor Rules and Prompts: What Goes Where

Put anything that should hold on every change into Cursor rules or AGENTS.md — short, composable, with examples — and keep the chat prompt about the task: the goal, the constraints for this change and how success is checked. Rules are guidance the agent may follow, not enforcement, so anything critical also needs a test or CI check.

Written by Vibrr Engineering · Published 2026-09-18 · Claims last verified 2026-09-18 · Not independently reviewed

Vibrr is an independent product. It is not affiliated with, endorsed by or sponsored by Cursor. Product names are trademarks of their respective owners and are used here only to describe compatibility and content.

The documented rule modes

How Project Rules are applied, per Cursor's documentation
Mode	Behavior	Good for
Always Apply	Included in every chat session	Short, universal conventions
Apply Intelligently	The agent decides relevance from the rule's description	Guidance that matters only for some tasks
Apply to Specific Files	Auto-attached when a file matches a glob pattern	Directory- or language-specific standards
Apply Manually	Included only when you @-mention it	Rarely needed procedures

Rules are stored as .mdc files with frontmatter in .cursor/rules. Plain .md files there are ignored unless named AGENTS.md, which Cursor also supports in the project root and in subdirectories.

Where should this instruction go?

This procedure is Vibrr's engineering guidance; each destination it names is a documented Cursor mechanism.

Instruction placement
The instruction…	Put it in	Because
applies to every change in this repo	Project Rule (always), or AGENTS.md	It is version-controlled and shared with the team
applies to one directory or file type	Project Rule scoped by glob	It attaches only when relevant
is a personal style preference	User Rules	It follows you but is not applied to Inline Edit
is company policy for a team	Team Rules	Managed centrally; Team and Enterprise plans
is about one task	The chat prompt	It should not outlive the task
must hold no matter what	A test, linter or CI check — plus a rule if useful	Rules do not govern every AI feature

Writing rules that earn their place

Stay under 500 lines per rule and split large ones.
Reference files instead of pasting them, and give concrete examples.
Write for a new teammate: specific and checkable, never vague.
Do not duplicate what the codebase or the agent already knows.

What a good task prompt contains

With durable standards moved into rules, the task prompt can stay short and precise. Vibrr's structure for an existing repository:

Task prompt (Vibrr template)

Goal: <the change, in one or two sentences>
Scope: <files or directories involved; what must not change>
Follow: @<file that shows the pattern to copy>
Acceptance: <the checks that must pass — tests, typecheck, behavior>
Report: show the command output that proves the checks passed.

The Vibrr compiler workflow, with a real example

Vibrr compiler output for an existing-repository task. The base specification and acceptance criteria are identical on every platform; only the adaptation section is Cursor-specific.

Example brief: Add server-side pagination to the invoices list in an existing billing service. The list must accept a page size up to 100, return a stable order, and keep the current response shape for existing clients. Update the tests and the API documentation.

Compiled prompt — Cursor, task: existing repository

# Base specification

Add server-side pagination to the invoices list in an existing billing service. The list must accept a page size up to 100, return a stable order, and keep the current response shape for existing clients. Update the tests and the API documentation.

# Acceptance criteria

1. The project installs and builds from a clean checkout using documented commands.
2. Every requirement in the specification is implemented or explicitly reported as not implemented.
3. Protected data and actions are authorized on the server, not only hidden in the UI.
4. Loading, empty and error states exist for every data-dependent view.
5. No secrets are committed or shipped in the client bundle; required environment variables are documented.
6. Automated checks (tests, typecheck, lint) are provided and their output is reported.

# Engineering requirements


# Platform adaptation: Cursor

Workflow this prompt is written for: Repository context → rules → agent → code changes → verification.

Put durable constraints in Project Rules or AGENTS.md — one composable rule per concern, under 500 lines, with concrete examples or referenced files — then keep the chat prompt about the task.

Work in this order:
1. One rule per concern, described so the agent can decide when it applies
2. Concrete examples or @-referenced files rather than pasted style guides
3. Task prompt states the goal, constraints and how success is checked

Documented platform constraints to respect:
- Rules do not impact Cursor Tab or other AI features.
- User Rules are not applied to Inline Edit (Cmd/Ctrl+K).
- Plain .md files in .cursor/rules are ignored unless the file is named AGENTS.md.

Known failure modes to avoid:
- Assuming rules govern every AI surface — Do not rely on rules alone for must-hold constraints; back them with tests, lint and CI that run regardless of which surface wrote the code.
- Oversized or vague rules — Keep rules under 500 lines, split them into composable rules and reference files instead of copying them.

# Verification

Report evidence (command output, test results), not assertions:
- Run the project's tests/typecheck after the change
- Review the diff against the stated constraints

What the compiler decided

Strategy: Encode standards as scoped, composable rules before prompting (cursor.existing-repository.rules-first)
Knowledge version: 2026-09-18.1
Evidence behind the adaptation: cursor.existing-repository.rules-first (documented); cursor.rules-scope-gap (documented); cursor.bloated-rules (documented); cursor.rules-not-tab (documented); cursor.user-rules-not-inline-edit (documented); cursor.plain-md-ignored (documented)
Assumptions: Requires from the requester: Repository conventions the agent cannot infer. Requires from the requester: Files worth referencing as examples.
Prompt checks (heuristic): requirementCoverage: pass · ambiguity: pass · platformCompatibility: pass · architectureConsistency: warn · unsupportedClaims: pass · missingAcceptanceCriteria: pass · securityGaps: pass · testability: pass · deploymentReadiness: pass · contextCompleteness: pass

The adaptation section is drawn from the same sourced knowledge that powers the Cursor guide, so the page and the compiler cannot disagree.

Failure modes to design around

Failure modes for Cursor that a source documents or an experiment supports

Assuming rules govern every AI surface

Documented guidance — how often it happens has not been measured

Trigger: A must-hold constraint lives only in a rule, but the change is produced through Tab or Inline Edit.
Symptom: The constraint is silently absent from that output.
Risk: Convention or security requirements bypassed without any error.
Prevention: Do not rely on rules alone for must-hold constraints; back them with tests, lint and CI that run regardless of which surface wrote the code.
Verify: Enforce the constraint in CI and check that it fails on a deliberately violating change.

Source: Rules — Cursor Docs

Oversized or vague rules

Documented guidance — how often it happens has not been measured

Trigger: Copying whole style guides, documenting commands agents already know, or writing rules for rare edge cases.
Symptom: Rules that are long, vague and duplicate existing documentation.
Risk: Wasted context and weaker adherence to the rules that matter.
Prevention: Keep rules under 500 lines, split them into composable rules and reference files instead of copying them.
Verify: Review each rule: would removing it change the agent's output? If not, delete it.

Source: Rules — Cursor Docs

Prompt patterns for Cursor

Encode standards as scoped, composable rules before prompting

Documented · task: existing repository

Pattern: Put durable constraints in Project Rules or AGENTS.md — one composable rule per concern, under 500 lines, with concrete examples or referenced files — then keep the chat prompt about the task.
Use when: Any repository where the same corrections would otherwise be repeated in every chat.
Skip when: A one-off instruction that will never apply again; put it in the prompt.
Bring: Repository conventions the agent cannot infer; Files worth referencing as examples
Check: Run the project's tests/typecheck after the change; Review the diff against the stated constraints

Source: Rules — Cursor Docs

Sources

Sources reviewed for Cursor

Rules — Cursor Docs — Cursor, read 2026-09-18. docs.cursor.com/context/rules returned a 308 permanent redirect to cursor.com/docs; the rules page at the new location was read.

Frequently asked questions

What is the difference between Cursor rules and prompts?

Rules are persistent instructions stored with the repository or your account; a prompt is the instruction for one task. Put durable standards in rules and keep prompts about the task.

Does Cursor read AGENTS.md?

Yes. Cursor's documentation lists AGENTS.md as a plain markdown alternative to .cursor/rules, supported in the project root and in subdirectories.

Is there a Cursor prompt generator?

Vibrr generates a Cursor prompt from a brief. The example above is real output of Vibrr's prompt compiler for an existing-repository task; the app's generator currently covers initial builds, so this form is not yet available there. Vibrr is independent and not affiliated with Cursor.

Official and primary sources

Rules — Cursor Docs — Cursor, read 2026-09-18. docs.cursor.com/context/rules returned a 308 permanent redirect to cursor.com/docs; the rules page at the new location was read.