Windsurf AI Rules: Files, Examples, and Scope
Windsurf (now Devin Desktop) uses project-level rule files to shape how the coding assistant behaves. Here is how to write and scope those rules with concrete examples.
Updated 6 min read
Windsurf, now renamed Devin Desktop, reads rule files you place in your project to shape how the coding assistant behaves in that codebase. Rules tell the assistant which patterns to follow, which to avoid, and what context it needs before making changes. A rule file is one of the most direct ways to make an AI coding assistant consistently useful for your specific project.
Storing your approved project rules in a portable place matters when you use more than one assistant. fenbs keeps your Decisions and rules in a shared record that Claude Code, Cursor, and other connected tools read at the start of each session, so the same rules apply everywhere.
What rule files do in Windsurf and Devin Desktop
Rule files inject standing instructions into every session in that project. The assistant reads them before starting work, so the rules apply without you having to repeat them each time. Rules can cover code style, architecture choices, forbidden patterns, testing requirements, and any project-specific context the assistant needs to do useful work.
Windsurf was renamed to Devin Desktop. If you were using Windsurf rule files, the same files continue to work in Devin Desktop. Check Devin Desktop's documentation (opens in a new tab) for the current file name, location, and syntax, as these can change between versions.
Where rule files live
Project-level rules go in a file in your project root. The file name and format may change with application versions; check the current documentation. Global rules that apply across all projects go in a settings location within the application. Project rules take precedence over global rules when both cover the same topic.
Committing the rule file to your repository means every team member who opens the project in Devin Desktop gets the same rules automatically. This is the best practice for team projects: the rules are version-controlled alongside the code they govern.
Writing rules that hold
A rule that the assistant ignores is usually one of three things: too abstract, too long, or in conflict with another rule. Concrete rules with specific examples are followed more consistently than general principles.
Structure each rule as: what to do or not do, and an example if the case is not obvious. Keep the full rule file to a length you can read and maintain. Rules near the end of a long file receive less attention than rules at the top.
Example rules that work well
Here are concrete rule examples across common categories. Adapt them to your project:
| Category | Rule example |
|---|---|
| Testing | Every new function must have at least one unit test in the corresponding test file. Do not add a function without adding a test. |
| Error handling | Do not use bare catch blocks. Every catch must log the error and either rethrow or handle it explicitly. |
| Naming | Use camelCase for variables and functions, PascalCase for classes and types. Do not use single-letter variable names except in short loops. |
| Dependencies | Do not add new npm dependencies without asking. Prefer the existing utility library in /src/utils before introducing a new package. |
| Comments | Add a comment only when the code does not explain itself. Do not add comments that restate what the code does in plain English. |
| Architecture | All API calls go through /src/services. Do not call fetch or axios directly from a component. |
| Security | Do not log user data, tokens, or personally identifying information. Check for this in every new logging statement. |
Keep project rules where every assistant reads them
In fenbs, record each architectural and code rule as a Decisions and rules entry. Claude Code, Cursor, and any other connected assistant reads those rules at the start of a session via MCP. When a rule changes, update it once in fenbs and every connected tool gets the update. Create a free account and record your first project rule today.
Create a free accountFree for one person · No credit card · Works with Claude, ChatGPT, Cursor and more
Scoping rules to a project or workspace
Some rules apply to every project you work on; others apply only to one codebase. Put project-specific rules in the project rule file and commit it to the repository. Put global rules that apply to all your projects in the global settings of the application.
Avoid putting rules in the global settings that only make sense for one project. A rule about a specific framework or library from one project applied globally will produce confusing suggestions in unrelated projects.
Keeping rules consistent across assistants
If you use Devin Desktop for some tasks and Claude Code or Cursor for others, the same project rules should apply in all three. Duplicating rule files across tools creates a maintenance problem: when a rule changes, you have to update it in every place.
Storing your project rules as Decisions and rules in fenbs solves this. Any assistant connected to fenbs reads the current rules at session start, regardless of which app it runs in. For setup, see /integrations. For a broader look at rule files in coding assistants, see cursor rules for AI projects.
How to do this with fenbs
- Create a free account and add a project for the codebase these rules govern.
- Add each rule as a Decisions and rules entry in fenbs: what the rule is, why it exists, and who decided it.
- Commit the rule file to the repository so every team member gets the rules automatically in Devin Desktop.
- Connect Claude Code, Cursor, or other tools at /integrations to read the same rules via MCP.
- When a rule changes, update the Decisions and rules entry in fenbs and the rule file in the repository at the same time.
For related reading, see what is an AI brain for the broader concept behind shared project rules, or how to use AI at work for practical patterns across tools.