Import Cursor Rules: Reuse Files Without Copying Mistakes

Importing Cursor rules from another project means copying the rule files, reviewing every assumption they contain, and adapting the globs and paths to your project's layout. A rule that works well for one codebase may assume a folder structure, a specific package manager, or a test framework your project does not use.

fenbs stores the approved source templates and the project-specific decisions that override them, so the next assistant session knows what was taken from a shared library and what was changed for this project and why.

What importing rules actually means

Cursor does not have a built-in mechanism for importing or extending rule files from an external source the way package managers import libraries. Importing rules means copying .mdc files into your project's .cursor/rules/ folder and adapting them.

Some teams maintain a shared repository of rule templates and copy from it when starting a new project. Others import from a published collection. Either way, the rule files you end up with are local to your project. Cursor reads them from your local filesystem; it does not fetch them from a remote URL.

Review assumptions before relying on an imported rule

A rule from another project was written for that project. It may reference folder paths that do not exist in yours, command names that differ in your package manager, or test frameworks your project does not use. Before relying on an imported rule, read it line by line and check each assumption against your project.

• Folder paths: does src/components/ exist in your project, or is it app/components/ or something else?
• Commands: does the rule say npm test when you use pnpm test?
• Dependencies: does the rule reference a linter, formatter, or test library your project does not have?
• Globs: do the file patterns match your file naming conventions?
• Scope: does the rule apply to your project's domain, or was it written for a different tech stack?

Adapting the scope

The most common adaptation is the glob pattern. A rule written for a project that uses .spec.ts for tests needs its glob changed if your project uses .test.ts. A rule that references src/ needs updating if your project uses app/ or has a monorepo layout.

Beyond paths and globs, review the technology assumptions in the rule. A rule written for a React project may assume JSX, component-level state, or a specific testing library. If your project uses a different framework, those assumptions produce incorrect guidance. Reading line by line rather than scanning for obvious path references catches the assumptions that sit in the middle of an otherwise general instruction.

After changing the globs, test the rule on a representative task in your project. Ask the assistant to work on a file that should trigger the rule and confirm it describes the correct approach. A changed glob that accidentally excludes files silently stops the rule from applying.

Before using an imported rule:
1. Read every line and list the assumptions.
2. Check each assumption against your project layout.
3. Update folder paths to match your structure.
4. Update command names to match your package manager (npm/pnpm/yarn/bun).
5. Update the glob pattern to match your file naming convention.
6. Remove lines that reference tools your project does not use.
7. Test on a representative task and confirm the rule activates correctly.
8. Record the source and any changes in fenbs.

Keeping track of sources and overrides

When a rule is imported from a shared library, the source matters. If the library is updated to fix a bug, you want to know which of your rules came from it. A comment at the top of the imported file naming the source and the date you copied it makes that tracking possible.

Version tracking is also useful when a source library releases an update. If you copied a rule six months ago and the library has since fixed a mistake in it, you want to know which of your rules came from that source so you can evaluate the update. A comment at the top of each imported file is low-effort tracking with high-value returns when the source changes.

When you override a line from the source, a comment explaining why prevents the next person from reverting your change thinking it was a mistake. "Changed from npm test to pnpm test — this project uses pnpm" is obvious when written, invisible when omitted.

For building and maintaining a shared rule library, see cursor rules library. For understanding how multiple rules interact in the same project, see cursor rules hierarchy. For how glob patterns control when rules activate, see cursor rules globs.

How to import and manage rules with fenbs

1. Create a free account and add your project.
2. Copy the rule files from the source project or library into your .cursor/rules/ folder.
3. Review each imported file against your project. Note the assumptions that need updating and the lines to keep as-is.
4. Adapt the globs, paths, and commands. Add a comment naming the source at the top of each imported file.
5. Record the source template and any project-specific overrides in fenbs as Decisions, then connect Cursor via Integrations and test the rules on a representative task.

For more on the structure of rule files, see cursor rules examples and cursor rules for AI projects. For the glob syntax that controls when rules activate, see cursor rules globs.