Cursor Rules Examples for Coding Teams

These Cursor rules examples give a coding team three small .mdc files to adapt: a project-wide boundary, a file-scoped validation rule, and a rule invoked only when a handoff is requested. Put them in .cursor/rules/, change the illustrative paths and commands to match your repository, then check the rule activation in Cursor. The examples target ownership, validation, and handoff because those decisions often disappear between coding sessions. They do not grant permissions, run tests, or supply current project state.

As of October 2026, Cursor’s project rules documentation says project rules are version-controlled .mdc files. It defines activation using three frontmatter fields: alwaysApply, globs, and description. The examples below follow that table. They are original templates, not excerpts from a customer repository. Their frontmatter was checked locally; the examples were not exercised in a Cursor Agent session against a sample app.

Choose the activation mode before writing the rule

A rule that should apply to every Agent chat uses alwaysApply: true. Cursor ignores globs and description for that mode, so leave them out. For files in context, use alwaysApply: false plus globs; Cursor auto-attaches the rule when a file matches. For relevance-based selection, use alwaysApply: false and description without globs. To require an explicit @-mention, use alwaysApply: false alone. These combinations are in Cursor’s activation table; they are easy to confuse if you add a helpful-sounding description to a manual rule.

• Always: a short boundary that should be present in each Agent conversation.
• File-scoped: instructions tied to a concrete set of paths, attached when matching files enter context.
• Agent-selected: a description lets Cursor decide relevance; useful when paths cannot express the trigger, but selection needs checking.
• Manual: no description or globs metadata; invoke by @-mention only for an occasional workflow.

A project rule is prompt guidance, not a file permission or policy enforcement mechanism. Cursor says its contents enter the model context when applied. Review the agent’s actual edits and run your repository’s checks. Cursor also says a plain .md under .cursor/rules is ignored; use .mdc there, or use AGENTS.md for simple plain-Markdown repository guidance. Keep each rule focused rather than pasting a whole style guide into every conversation.

Example 1: project-wide ownership boundary

Save this as .cursor/rules/project-ownership.mdc. It is intentionally short enough for every conversation. In the fictional repo below, generated files and database migrations have named owners. Replace those examples with your actual ownership map. The rule asks for a check before edits and for evidence after edits; it does not make the editor enforce the boundary.

---
alwaysApply: true
---

# Project ownership

Before editing, name the requested behavior and the paths you expect to touch.
Read the nearest repository instructions and the owning module before changing a file.
Treat generated files and database migrations as separately owned surfaces.
If a change needs an unrequested owner or directory, stop and ask for that scope.
Preserve unrelated work in the checkout.
At handoff, report changed paths, checks actually run, and unresolved questions.

There is no description or globs field because alwaysApply: true already controls activation. Cursor’s documentation says those other fields are ignored in this mode. This rule carries durable boundaries, not a changing list of who is assigned today. A repo with a central ownership document can refer to that file rather than duplicate its entire contents, though the agent must read the referenced file when it needs details.

Example 2: validation for API handlers

Save this as .cursor/rules/api-validation.mdc in the illustrative TypeScript project. The pattern is deliberately limited to app/api/**/*.ts. Cursor documents ** as recursive and lists comma-separated patterns for multiple areas. Confirm that the pattern covers your real handler files; for example, a repository with src/app/api/ needs a different prefix. Activation occurs when a matching file is in context, not on every chat about an API.

---
globs: app/api/**/*.ts
alwaysApply: false
---

# API handler validation

For a changed handler, read its request schema and the tests that exercise it.
Validate untrusted input at the boundary using the project’s existing validator.
Keep authorization checks in the handler or its established policy layer.
Add the smallest durable test for a changed outcome or rejection path.
Run the handler’s focused test command from the documented working directory.
Report the command and result; if it could not run, state why.
Do not claim a response is correct solely because the rule was attached.

This rule does not include description metadata: globs plus alwaysApply: false is sufficient for file-scoped activation. An optional human note belongs in the body, where it cannot change the activation mode. The command is deliberately described rather than fabricated because test scripts vary by repository. Replace that line with your actual focused command after checking package scripts. A rule may request validation, but only an observed test run supplies evidence.

Example 3: manually requested handoff

Save this as .cursor/rules/session-handoff.mdc. It has neither description nor globs in frontmatter. Ask Cursor Agent to apply @session-handoff when work must cross to another session or person. The body separates completed work from proposals so a later reader can continue without treating guesses as facts.

---
alwaysApply: false
---

# Session handoff

When explicitly invoked, write a concise handoff for the named task.
Include the objective, changed paths, and decisions confirmed by the requester.
List commands actually run with pass, fail, or skipped outcomes.
Mark inferred causes and proposed next steps as unverified.
Name the next owner only when the requester or shared work record identifies one.
Check the current work item before reporting its stage or blockers.
Do not mark work complete or write a shared ticket without the needed authority.

A line such as description: Prepare handoffs would turn this into an agent-selected rule under Cursor’s current table. Omit it for manual activation even if a form calls its human-facing label a “description.” The filename gives people a name to mention. To use it, say “Apply @session-handoff to this task; include the paths and checks from this session.” Then inspect the result against the transcript and the current work record.

Try the examples without assuming they worked

1. Create the three .mdc files under .cursor/rules/ and replace illustrative paths, ownership claims, and checks with facts from your project.
2. Open Cursor’s rule controls and verify that project-ownership is always applied, api-validation is file-scoped, and session-handoff is manual.
3. Bring a matching API file into Agent context, request a small bounded edit, and inspect whether the validation rule was attached. Do not infer attachment from a convincing answer.
4. Run your real focused tests and review the diff. Ask for @session-handoff only when a handoff is needed, then check every reported path and result.

Cursor’s best-practices guidance favors focused, actionable rules and warns against copying whole style guides or repeating what the codebase already says. If one rule keeps growing, split it by trigger and owner. If a rule is repeatedly ignored, first check its activation, glob, and specificity. Do not add more words to an inactive file and expect that to fix attachment.

Static instructions and live shared work have different jobs

Rules encode a standing way of working. They cannot know whether another agent claimed today’s ticket, which approval is pending, or what changed after the rule was committed. Cursor’s MCP documentation describes connecting external tools through project .cursor/mcp.json; that connection is separate from project rules. A rule can tell an agent when to consult a shared source, but the source and the current authorization determine what it can read or write.

For example, AppHandoff’s documented MCP endpoint is https://api.apphandoff.com/mcp. Its current MCP overview and client connection guide explain the shared record and client setup. The served tools are bootstrap, get, find, ticket, plan, message, project, and decide_lifecycle_proposal. An agent can resolve a project with bootstrap and read a card with get or find when its account has access. Writes require the appropriate scope and current rule checks; decide_lifecycle_proposal belongs to a signed-in human approval card, not an agent action. A rule never supplies that approval.

A practical handoff can therefore cite the ticket it actually read, the paths it changed, and the test output it observed. If the connected client lacks access, say so and ask for the right connection rather than inventing current status. For a wider view of shared context across editors, see coordination across Claude Code, Cursor, and Codex. The same distinction holds without AppHandoff: a checked-in rule is durable guidance, while a live board or repository state answers what is true now.

Use the generator for a first draft

If you want to assemble your own activation mode, boundaries, validation instructions, and return evidence, the Cursor rules generator formats your inputs as a .mdc draft. It is deterministic: it does not inspect your repository, test glob matches, install the rule, run commands, or verify that Cursor followed it. The three examples here show why you might choose each scope; the generator saves typing after you decide what your actual project needs. Review its output and activation in Cursor before committing it.