Cursor rules vs Cline rules
The same 6 criteria for both, with the page each figure came from and the day it was read.
Which one, and when
On where the file lives, Cursor rules is .cursor/rules/*.mdc and Cline rules is .clinerules/ at the project root. On per-directory files, Cursor rules is Folders inside .cursor/rules, for organisation and Cline rules does not publish it. On path-scoped rules, Cursor rules is Yes, globs, description or @-mention and Cline rules is Yes, paths frontmatter. On what wins on a conflict, Cursor rules is Team rules take precedence and Cline rules is Workspace beats global. On published size guidance, Cursor rules is Under 500 lines per rule and Cline rules does not publish it. On what its own docs say about rival formats, Cursor rules is Names AGENTS.md as the plain-markdown option and Cline rules is Reads .cursorrules, .windsurfrules and AGENTS.md. RuleStack sells neither of these and takes no referral fee on either, it scores them. Every figure was read off the named company's own page on or since 2026-09-13; the URLs and the dates are at the foot of this page, and a job re-fetches each one on a schedule and fails when a figure is no longer on the page it came from.
Cursor rules vs Cline rules, row by row
Read 13 September 2026Every figure was read off the named company's own page on or since 13 September 2026. A job re-fetches each URL on a schedule and fails when a figure is no longer on the page it came from.
One paragraph per format, in its own terms
Pick Cursor rules when
You want a rule that only loads when it is relevant, and you want the agent, not a glob you maintained by hand, to make that call. Cursor is the only one of the five whose docs publish the full decision table for when a rule is included: `alwaysApply: true` always, a `globs` pattern on a file match, a `description` alone when "agent reads the description and pulls the rule in when relevant", and nothing at all until you @-mention it. Nobody else documents a description-triggered rule, and on a large repository that is the difference between five rules in context and fifty.
Pick Cline rules when
You want to turn a rule off for an afternoon without deleting it, and you have inherited rule files from three other tools. Cline is the only one of the five that documents a per-rule toggle in the UI, "you might have a strict testing rule that you want to disable when prototyping", and the only one whose docs say it reads .cursorrules, .windsurfrules and AGENTS.md automatically as well as its own format, which makes it the cheapest of the five to adopt on a repository that already has rules in it.
One question, one answer, nothing collapsed
Cursor rules vs Cline rules, where the file lives?
Cursor rules: .cursor/rules/*.mdc. "Project rules live in .cursor/rules as .mdc files and are version-controlled." A plain .md file in that directory is ignored: "api-guidelines.md # ignored (wrong extension)". Cline rules: .clinerules/ at the project root. "Workspace rules go in .clinerules/ at your project root." Cline "processes all .md and .txt files inside .clinerules/, combining them into a unified set of rules"; global rules live in a separate per-OS directory. Read from cursor.com and docs.cline.bot on 2026-09-13.
Cursor rules vs Cline rules, per-directory files?
Cursor rules: Folders inside .cursor/rules, for organisation. The documented layout puts subfolders inside the one rules directory, "frontend/ # organize rules in folders", rather than a rules directory beside each package. For per-directory files Cursor's own page points elsewhere: "Cursor supports AGENTS.md in the project root and subdirectories.". Cline rules does not state it on docs.cline.bot. The documented layout is one .clinerules/ directory at the project root plus a global one; this page describes no per-package rules directory. Cline's answer to the same problem is the paths frontmatter rather than file location. Read from cursor.com and docs.cline.bot on 2026-09-13. Per-directory files here means whether the format documents putting a second file next to the code it governs, rather than one file at the repository root.
Cursor rules vs Cline rules, path-scoped rules?
Cursor rules: Yes, globs, description or @-mention. Four documented rule types. "Apply to specific files When file matches a specified pattern", and the frontmatter table spells out what each combination of alwaysApply, description and globs does. Cline rules: Yes, paths frontmatter. "Conditional rules let you scope rules to specific parts of your codebase. Rules activate only when you're working with matching files." Written as YAML frontmatter on any rule file; "a rule activates if any pattern matches any file in your context". Read from cursor.com and docs.cline.bot on 2026-09-13. Path-scoped rules here means whether a rule can be limited to files matching a pattern instead of loading into every request, which is the mechanism that decides how much of your context window the file costs.
When should I pick Cursor rules, and when Cline rules?
Cursor rules, You want a rule that only loads when it is relevant, and you want the agent, not a glob you maintained by hand, to make that call. Cursor is the only one of the five whose docs publish the full decision table for when a rule is included: `alwaysApply: true` always, a `globs` pattern on a file match, a `description` alone when "agent reads the description and pulls the rule in when relevant", and nothing at all until you @-mention it. Nobody else documents a description-triggered rule, and on a large repository that is the difference between five rules in context and fifty. Cline rules, You want to turn a rule off for an afternoon without deleting it, and you have inherited rule files from three other tools. Cline is the only one of the five that documents a per-rule toggle in the UI, "you might have a strict testing rule that you want to disable when prototyping", and the only one whose docs say it reads .cursorrules, .windsurfrules and AGENTS.md automatically as well as its own format, which makes it the cheapest of the five to adopt on a repository that already has rules in it.