How to Use Cursor Rules in GitHub Copilot
Move the useful content of your Cursor rules into instruction files Copilot supports. Translate when each rule applies, then check that it loads for the right task.
Updated 5 min read
To use Cursor rules in Copilot, move their instruction text into supported Copilot files and translate the conditions that decide when it loads. Put repository-wide guidance in .github/copilot-instructions.md and use .github/instructions/NAME.instructions.md with applyTo for file-specific guidance where your Copilot environment supports it.
Copying a .mdc file into a new folder is not enough: its Cursor settings need review. Tools like fenbs keep the project’s approved decisions in a shared record, so the local files do not become competing accounts of what the team agreed.
How do you move a Cursor rule into Copilot?
- List the Cursor rules you actually use. For each, record its purpose, whether it is always included, and which files or tasks should trigger it.
- Choose the Copilot environment you are setting up. Check its instruction support rather than assuming an editor, GitHub.com, and a command-line session load everything alike.
- Move general instructions into the repository-wide file. Put instructions limited to a particular folder or file type into supported path-specific files.
- Replace Cursor activation metadata with the target format. Review file references and commands instead of copying Cursor-only syntax unchanged.
- Test one matching task and one task outside the intended scope. Inspect the instructions included in the request and the resulting behavior.
Cursor’s rules documentation (opens in a new tab) describes project rules as .mdc files in .cursor/rules, with settings for always applying, file matching, relevance, or manual use. Treat that inventory as the starting point. The Cursor rule examples help you recognize those patterns in a real repository.
Which instructions should be repository-wide?
Move only the rules that make sense across the repository into .github/copilot-instructions.md. Good candidates include the package manager, the actual validation commands, the location of generated files, and project-wide conventions. Read every line as if Copilot were working on an unrelated folder.
# Project instructions - Use pnpm for package commands. - Keep changes focused on the requested task. - Do not edit src/generated/; change its source schema instead. - Report the validation commands you ran and their results. - If a required check cannot run, say which check and why.
Adapt this example to commands and paths that really exist in your project. Do not put a database-only convention here simply because it appeared in a long Cursor file. Making every rule global can make a small documentation change inherit irrelevant instructions about database access.
GitHub documents repository-wide and path-specific files in its repository instruction guide (opens in a new tab). On GitHub.com, the guide limits path-specific support to Copilot cloud agent and code review. Check that distinction before expecting the same file to shape every Copilot conversation.
How do you translate a file-scoped rule?
Keep the instruction body, then restate its scope in Copilot’s format. The example below covers TypeScript files inside src/api/. The small metadata block between the lines of three hyphens is called frontmatter; it describes how the instruction should apply.
--- description: API conventions globs: src/api/**/*.ts alwaysApply: false --- Use the existing request validation helpers. Keep database access in the repository layer. Add coverage for an invalid request when changing validation.
--- applyTo: "src/api/**/*.ts" --- Use the existing request validation helpers. Keep database access in the repository layer. Add coverage for an invalid request when changing validation.
Remove globs and alwaysApply rather than leaving them as if they still control Copilot. Then check representative paths: a direct file in the API folder, a nested file, and a file outside it. Matching syntax that looks similar still needs a test in the destination tool.
For editor setup, use GitHub’s IDE-specific instruction guide (opens in a new tab) and choose your editor’s tab. Do not treat instructions for VS Code as a promise about Visual Studio or a JetBrains editor. Broader file-pattern design belongs in the separate Cursor rules guide.
What happens to manual and relevance-based rules?
Decide their intended trigger before converting them. A Cursor rule that you request manually may describe a particular review or release task. Turning it into an always-applied instruction changes its meaning, even when you copy its words perfectly.
| Original intent | A practical migration choice |
|---|---|
| Applies across the whole repository | Keep concise guidance in .github/copilot-instructions.md. |
| Applies only to matching files | Use a supported .instructions.md file with an applyTo pattern, then test it. |
| Requested manually for a special task | Keep it as a deliberately supplied task prompt or attachment until you verify a supported reusable format. |
| Chosen when the assistant considers it relevant | Review the destination tool’s discovery options; use explicit attachment when you need predictable inclusion. |
Also rewrite tool-specific file mentions as clear repository paths and explain what to inspect there. A useful shared instruction says what evidence the assistant needs. It should not rely on an editor shortcut that becomes ordinary text after migration.
How can you verify Copilot used the file?
Start with a harmless task whose success is easy to inspect. For the API example, ask Copilot to propose a validation change in an existing API file and explain which helper it would use. Compare that with a documentation task that should not need the API-specific file.
The VS Code instructions guide (opens in a new tab) recommends checking discovery in Agent Customizations, starting a new chat, and expanding References to see which instructions were included. Use the intended Copilot session for that check. Finding a file in the customization list establishes discovery, not compliance.
Inspect the proposed change too. Did Copilot use the existing helper? Did the relevant checks run? If an instruction is missing, investigate its location, scope, and enabled settings. If it was included but ignored, make the requirement more concrete and remove conflicts before adding more text.
This test checks instruction transfer, not which assistant is better at every coding task. For that broader choice, see Claude Code, Cursor, and Copilot compared.
How do you keep the two versions from drifting?
Give each durable rule an owner and a reason. When a person changes the rule, review both local representations in the same change. Keep a short mapping of the Cursor filename, the Copilot filename, and the intended scope so a later editor can find the matching instruction.
Changing task state needs a different home. A rule can say to record test results; it should not become a diary of every test run. Save the current decision, unresolved question, and next step in a shared project record that both assistants can read through fenbs integrations.
Keep the project when you switch coding tools
Connect Cursor and GitHub Copilot to the same fenbs project and ask both to read its Rules and Where we left off. People approve decisions; assistants can record them and save task progress. The instruction files still tell each tool how to work locally, while the shared record says what the work needs next.
Create a free accountFree for one person · No credit card · Works with Claude, ChatGPT, Cursor and more
How to do this with fenbs
- Create a free account and add the project whose instructions you are moving.
- Record the rules a person has approved in Decisions and rules, including their scope and reason. Keep undecided choices open.
- Connect Cursor and GitHub Copilot using their setup guides. Ask each to read the same project context before starting.
- Save the migration as a task with the file mapping and the checks you performed. Before switching tools, save Where we left off and any remaining work.
fenbs does not convert .mdc files or control Copilot’s instruction loading. A repository-only setup may be enough if you just need static guidance in one editor. The switching-models hub covers the wider problem of carrying project work between assistants.