Cursor Rules Globs: Match the Files You Mean

A glob pattern in a Cursor rule is the filter that decides which files the rule applies to. Without one, a coding convention rule reaches markdown files, test fixtures, and generated code — everywhere it was not meant to go. Getting the pattern right means the assistant receives focused guidance for the file it is actually editing. Teams that store their approved rule text in a tool like fenbs can include the intended glob alongside each rule, so scope decisions are shared and not buried in individual config files.

Cursor follows standard glob syntax: * matches any file name segment within one directory level, ** crosses directory boundaries, and ? matches a single character. Most Cursor rule files accept one or more glob patterns in a globs field at the top of the file.

How glob patterns work in a Cursor rule

When you open a file in Cursor, the editor checks which rules have a glob that matches the file path. A rule scoped to src/**/*.ts loads automatically for TypeScript files inside src/, but not for files in tests/ or the project root. A rule with no glob loads for every file, depending on whether it is set to always-on or manual mode.

Patterns are evaluated against the file path relative to the workspace root. A pattern of apps/web/src/**/*.tsx matches apps/web/src/components/Button.tsx but not apps/mobile/src/components/Button.tsx. In a monorepo, this lets each package carry its own focused rules without affecting other packages.

Useful glob patterns for common project layouts

• **/*.ts — all TypeScript files anywhere in the project.
• src/**/*.ts — TypeScript files under the src directory, at any depth.
• **/*.test.ts or **/*.spec.ts — test files only.
• apps/web/**/* — everything inside one workspace package.
• **/migrations/**/* — all migration files regardless of depth.
• src/**/*.{ts,tsx} — TypeScript and TSX in one pattern (where the rule format supports brace expansion).

Some rule formats accept a list of patterns. ["src/**/*.ts", "src/**/*.tsx"] covers both file types without duplicating the instruction. Check the Cursor documentation for your rule file format to confirm whether lists or brace expansion are supported.

How to write a scoped glob step by step

1. Write the instruction first. Once you know what it says, it is easier to decide which files should see it.
2. Start with a broad pattern like src/**/*.ts and verify it loads for the right file by checking the Cursor context panel.
3. Open a file that should not receive the rule and confirm it does not appear in context.
4. Narrow the pattern once the broad version works. Swap **/*.ts for src/api/**/*.ts if the rule is only relevant to the API layer.
5. Keep the pattern in version control alongside the rule file so teammates and future assistants can see the intended scope.

Matching subdirectories at any depth

The double star ** crosses directory boundaries. The pattern src/**/services/*.ts matches src/api/users/services/auth.ts as well as src/services/email.ts. A single star * only matches within one level: src/services/*.ts would miss src/api/services/auth.ts.

In practice, most rules should use ** unless the intent is specifically to match files at the top of a directory. A rule for "all TypeScript files in this package" should read apps/web/src/**/*.ts, not apps/web/src/*.ts, because the latter misses every file in a subdirectory.

---
description: React component conventions for the web app
globs: apps/web/src/**/*.tsx
---

Use functional components with explicit props interfaces.
Keep the interface in the same file as the component.
Do not use class components or inline styles.

Common glob mistakes and fixes

• Using * where ** is needed: src/*.ts only matches files directly inside src, not in subdirectories. Replace with src/**/*.ts.
• Omitting the extension: src/**/* matches images, JSON, and everything else. Add the extension to keep the rule focused.
• A pattern too wide for a specific instruction: a rule about database migration naming should be scoped to migration files, not all TypeScript.
• Two rules with overlapping globs: both will load for matching files. See cursor rules hierarchy for how Cursor resolves overlapping instructions.

How to do this with fenbs

1. Create a free account and add a project for the codebase where your Cursor rules live.
2. Add a skill or prompt entry for each agreed rule. Include the target glob in the text, for example "scope: apps/web/src/**/*.tsx", so the intended file coverage is visible to teammates.
3. Record the reasoning in Decisions and rules: for example, "migration rules are scoped to **/migrations/** and never to application code — decided by the team to prevent style instructions leaking into service files".
4. When the project gains a new directory layout, update the skill in fenbs. The next assistant connected over MCP reads the updated scope without a manual explanation.
5. Connect your AI tools from Integrations so they can list and read the rules library at the start of each session.

When no glob is the right choice

Some instructions belong everywhere: a rule not to log secrets, a note about the approved date format, or a reminder about which dependencies are allowed. These are reasonable candidates for global rules with no file filter. Keep the global list short — every extra global rule increases the chance of it conflicting with a scoped one. The effort of choosing a pattern upfront is small compared to debugging an instruction that reached a file it was never meant to reach.

If the same instruction appears in five scoped rules, it probably belongs in a single global rule instead. If a global rule keeps growing exceptions for specific file types, that is a signal to split it into focused scoped rules. The cursor rules library has examples of how teams organize both kinds.