Windsurf and Cursor Rules: How to Move Your Instructions

To move Windsurf and Cursor rules, preserve the instruction text and translate the settings that control when it applies. Test the destination with a small task before trusting it with ongoing work; changing a file extension alone does not preserve behavior.

Windsurf is now named Devin Desktop, as the vendor FAQ↗ (opens in a new tab) confirms. This guide covers both older Windsurf rule files and the current destination. A shared record such as fenbs keeps approved rules and project progress available when you change editors, while local files tell each coding assistant how to work in the repository.

What is the safest order for moving the rules?

1. Inventory project files and personal settings separately. For every rule, note its purpose, its current activation setting, and the files it should affect.
2. Keep a recoverable copy of the original. Choose one small rule to translate first, such as an instruction for reviewing a particular folder.
3. Create the destination rule with the correct file format and activation setting. Preserve its meaning before improving its wording.
4. Start a fresh conversation in the destination. Check the loaded instructions and ask for a read-only plan for a relevant file.
5. Test an unrelated file too. Only migrate the rest after the first rule applies where expected and stays out of unrelated work.

Use a short checklist for the move: source path, destination path, intended scope, and observed result. A successful save proves the file exists; a useful test shows whether the assistant receives and follows its instruction. Keep those two checks distinct when reporting the migration.

Which parts of a rule need translation?

Separate the body from the frontmatter, the settings between the opening separator lines. The body might say to explain a proposed data change before editing. The frontmatter decides whether that instruction appears every time, for matching files, when relevant, or only on request.

The Windsurf-style rules reference↗ (opens in a new tab) describes these triggers. Cursor’s rules documentation↗ (opens in a new tab) describes its corresponding settings and requires project rules to use .mdc files in .cursor/rules. Cursor uses alwaysApply, globs, and description rather than the Windsurf trigger field.

This is a translation of intent, so compare the actual settings after saving. For detailed pattern behavior and conflict resolution, use the separate guides to Cursor rule file patterns and rule hierarchy. Keep this migration focused on preserving the rule you already approved.

How do you move one instruction into Cursor?

Suppose a project rule requires a read-only review before changing a payment calculation. Keep that requirement in the body and choose the same intended activation. Here is an always-on example; the instruction is hypothetical, so replace it with the requirement your project actually uses.

---
trigger: always_on
---
Before changing payment calculations, explain the current behavior,
the intended change, and the checks you will run. Wait for approval.

---
alwaysApply: true
---
Before changing payment calculations, explain the current behavior,
the intended change, and the checks you will run. Wait for approval.

Create the destination through New Cursor Rule or write the file directly. An always-applied Cursor rule uses alwaysApply: true; a file-scoped one uses alwaysApply: false with its pattern. An intelligent rule needs a useful description, while a manual rule needs an explicit mention. Check these settings rather than retaining an unrecognized trigger line.

Review references as well. Cursor’s rules help page↗ (opens in a new tab) says a file reference points Agent toward a file it can read when needed; it does not paste that file into the prompt. Put a requirement that must always be available directly in the rule body. See Cursor rules examples for more focused instruction bodies.

Do you need a second copy when moving into Devin Desktop?

Check before making one. The Devin rules documentation↗ (opens in a new tab) says it can read Cursor rule files and Windsurf formats, and describes import controls. Current Devin Desktop prefers .devin/rules for native directory rules. Its FAQ also describes importing Cursor .mdc files into that directory.

Choose whether to retain the shared source file or maintain a native translation. Inspect the loaded rules before adding both. Two active copies can repeat a requirement, and later edits can leave them disagreeing. An import capability helps with setup; it does not show that your particular rule loaded or behaved correctly.

Plain AGENTS.md is another option both vendors document for project instructions. It suits a short common baseline. Keep conditional editor settings separate, and avoid replacing a carefully scoped rule with a broader instruction just to reduce the file count.

How can you tell whether the destination follows the rule?

Use the same small request in both editors and compare observable behavior. For the payment example, ask the assistant to identify the calculation and propose a change without editing. It should explain the current behavior and stop for approval. A correct summary alone is weaker evidence than following that stopping point.

• For a file-scoped rule, use one matching file and one outside the intended folder.
• For a manual rule, test with and without the explicit mention.
• For a relevance-based rule, try a clear matching request and review whether its description explains the intended use.
• Check referenced paths from the actual workspace and inspect conflicting personal or project instructions.

Rules guide an assistant; they do not create access restrictions or replace code review. Keep real permissions and project checks in place. Save the agreed requirement and the migration result in fenbs Decisions and rules when other assistants also need that agreement.

What work context should survive the editor change?

A rule explains how to behave, but it rarely explains which task is unfinished. Before switching, record the approved goal, changed files, checks actually run, remaining uncertainty, and next action. Say explicitly when a result is untested. The next assistant should compare that record with the files before continuing.

Keep reusable instructions separate from yesterday’s temporary workaround. A person may approve the payment review rule permanently while one test remains blocked today. Cursor rules for AI projects explains the relationship between repository guidance and active tasks.

How to do this with fenbs

1. Create a free account, then add the project whose instructions and unfinished work need to travel between editors.
2. Save reusable instruction text in Skills and prompts. Record the rules a person approved in Decisions and rules, including who decided and where they apply.
3. Connect the supported coding assistants through Integrations. MCP is a standard connection that lets an AI app use an outside tool; follow the guide and complete browser sign-in.
4. Ask each assistant to read the project context before starting. Before stopping, save task progress and Where we left off, including the translation checks and the next action.

fenbs does not convert editor rule files or import your editor conversations automatically. If you only need conventions inside one repository, local instruction files may be enough. Use the shared record when approved instructions and ongoing work must reach several assistants; the switching models topic covers that broader workflow.