A team has set every file in `.cursor/rules` to Always Apply, so each conversation opens with the whole rule set whatever files are being edited. Which alternatives describe how a project rule can otherwise reach Agent?

The principle — A project rule's frontmatter decides whether it loads at all. With alwaysApply: true the file joins every session; with alwaysApply: false, a globs entry auto-attaches the rule when a matching file is in context, a description lets Agent pull it in when it judges the rule relevant, and a file with neither waits to be @-mentioned.

Why the key is correct — Those three conditional modes are exactly what the documentation lists for project rules: scoped using path patterns, invoked manually, or included based on relevance. Because rule contents are injected at the start of the model context, an always-on set is paid for on every single request, whether or not the current work touches the code the rule describes. Scoping is how that cost comes down without deleting anything.

Why the others are wrong — Treating the rules folder as a config directory where presence equals activation is the belief that produces an all-always set in the first place; frontmatter, not location, is what decides. There is no priority number that elects one file and suppresses the rest, because all applicable rules are merged rather than ranked. And Agent does not quietly trim the set to fit: an oversized always-on rule set stays in context and crowds out the code you actually wanted read.

Remember this — Presence in the folder is availability; frontmatter is what makes a rule load.

Sources — Cursor's Rules documentation.