{
  "id": 19150513,
  "title": "How to write Cursor rules that the agent actually follows (with .mdc examples)",
  "url": "https://urgent.news/2026/11/09/how-to-write-cursor-rules-that-the-agent-actually-follows-with-mdc",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-11-09T12:27:17.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/ofir_saban_a14cc4bc21c433/how-to-write-cursor-rules-that-the-agent-actually-follows-with-mdc-examples-2j1o"
  },
  "original_language": "en",
  "account": "Writing Cursor rules that the agent actually follows can be a challenge. The agent doesn't know your project unless you explicitly tell it. That's why project rules are essential - they tell the agent once instead of every time you make a prompt.\n\nRules live in .cursor/rules/ as .mdc files, which are markdown files with a small frontmatter block. The three fields that decide when a rule is loaded are setup, use for, and alwaysApply. Setup determines when it loads, Use for specifies when to use it, and alwaysApply is false by default.\n\nThere are three types of rules: always-on rules, framework-specific rules, and niche topic rules. Always-on rules stay short, under 40 lines each, and everything framework-specific is scoped to globs so it doesn't consume context when editing SQL migrations.\n\nThe recommended structure is 00-project-core.mdc, 01-workflow.mdc, 02-security.mdc, 05-code-style.mdc, and 10-nextjs.mdc. Each rule has a description and specific details about how to implement it.\n\nFor example, 00-project-core.mdc contains the project context and definition of done, while 10-nextjs.mdc specifies nextjs app router conventions.\n\nSecurity rules are specified in 02-security.mdc for server code, and code style rules are in 05-code-style.mdc. Keep rules concrete and specific, and avoid vague rules like \"write clean code\". Skills are step-by-step procedures for tasks like reviewing diffs or writing tests, and should be kept separate from rules.\n\nLastly, the author recommends using VibeRules, which generates a ready .cursor/ folder with rules, skills, and prompt library based on your project stack, testing, styling, and team size.",
  "summary": "If you use Cursor every day, you've typed this more than once: \"No, we use the App Router.\" \"Don't use any .\" \"Put the test next to the file.\" \"Validate with zod.\" The agent isn't bad. It just doesn't know your project. Project rules are how you tell it once instead of every prompt. Here's the structure I've settled on after a lot of trial and error. How Cursor rules work (current format) Rules…",
  "key_points": [],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}