Windsurf System Prompts and Rules: What You Can Customize

Windsurf has been renamed to Devin Desktop. If you set up rules in Windsurf and are looking for how they carry over, the product is the same tool under a new name. Like other AI coding editors, Devin Desktop keeps a layer of built-in instructions you cannot change and a layer of project and global rules you can. Tools like fenbs store the decisions and rules that should apply across Devin Desktop, Cursor, Claude Code, and every other coding tool the team uses.

Check the Devin Desktop documentation↗ (opens in a new tab) for the current configuration format. File names and settings paths can change between product versions.

Built-in instructions vs. editable rules

Every AI coding tool ships with a base set of instructions that tell the model how to behave as a coding assistant. These are set by the vendor and are not editable. They cover things like how to read and write code, when to ask for confirmation before making changes, and how to present suggestions.

On top of those built-in instructions, Devin Desktop lets you add your own rules. These fall into two groups. Global rules apply across all projects and typically live in a user-level settings file. Project rules apply only to the project in the current directory and live in a project-level configuration file. When there is a conflict, project rules usually take priority.

Project rules in Devin Desktop

A project rules file lives in the project directory, which means it travels with the code when you share it or clone it on another machine. This is the right place for rules specific to a codebase: the stack, the naming conventions, the patterns to avoid, and the checks required before a change is considered done.

• Stack declaration: language, framework, major libraries.
• Naming and organization: how files and functions are named, which folders exist.
• Patterns to avoid: deprecated APIs, anti-patterns specific to the project.
• Required checks: "always run tests before declaring a fix complete."
• Off-limits areas: "do not change the database migration files."

Keep the rules file short and honest. A rule that nobody enforces is worse than no rule, because it gives the AI a false expectation that then fails in practice. Review the rules whenever the team makes a significant architectural decision and update them the same day.

Testing your instructions

After editing the rules file, open a new session in Devin Desktop and make a request that should trigger one of your rules. If you added a rule about not modifying migration files, ask the assistant to make a database change and see whether it complies, flags the constraint, or ignores the rule.

Vague rules are the most common source of failure. "Be careful about the database" is not testable. "Do not modify any file in the db/migrations folder without asking" is. Rewrite any rule that the assistant ignores as something specific enough that you could check it with a single test case.

For a broader view of how system prompts compare across coding tools, Windsurf vs. Claude Code compares the two tools' approaches. Context engineering vs. prompt engineering explains when a rule belongs in a project file versus when it belongs in the task description.

Sharing rules across coding tools

A common problem on multi-tool teams: the developer using Devin Desktop has a rules file, the developer using Cursor has a .cursorrules file, and the developer using Claude Code has an AGENTS.md. Each file diverges over time. Decisions get made in one place and not propagated to the others.

The practical solution is to keep the human-approved decisions in a single authoritative place and derive the tool-specific files from it. The approved decision is "we use Vitest, not Jest." Each tool's rules file implements that decision in its own format.

When the rules file is not enough

A rules file in the project directory handles the most common case: a single developer working in Devin Desktop on one codebase. It starts to break down when multiple developers use different tools, when the project has rules that span several repositories, or when the reasons behind the rules are not recorded anywhere.

Decisions that are not explained get questioned. A rule that says "do not use class components" in a React project is clear on its own; a rule that says "always use the legacy pagination API" is not. Record the reason next to the rule -- in the file itself, in a comment, or in a Decisions and rules record that points to the relevant project background.

How to do this with fenbs

1. Create a free account. Start with a personal kanban board for this project.
2. Add a task for the rules you are setting up. In the plan, list the key rules and which developer approved them.
3. For each standing rule -- a decision that applies from now on -- add it as a Decision in fenbs with the deciding person, their reason, and the date.
4. Connect your AI coding tools to fenbs over MCP from Integrations. Each connected tool reads your project Decisions and rules at the start of a session.
5. When the project rules file changes, update the corresponding Decision in fenbs so the record stays in sync.

For the full picture of how rules files work across coding tools, system prompt examples has ready-to-adapt patterns. Prompt engineering covers the principles behind writing instructions that hold up over time.