Cursor Rules for C#: A Project Template

A Cursor rules file tells the AI exactly how your C# project is structured and what conventions it must follow. Without one, the assistant guesses at your build commands, naming patterns, and testing setup. With one, it starts each session from the right baseline.

This page provides a template you can copy into your project, a guide to the sections worth customizing, and notes on what to keep in a rules file versus what to keep in a shared project tool. For project-level decisions that change over time, tools like fenbs keep the record outside the static rules file so different coding assistants read the same current constraints.

Where Cursor reads rules in a C# project

Cursor reads rules from .cursor/rules/ (a directory of .mdc files) in newer setups, and from a .cursorrules file in the project root in older setups. Both work; the directory approach lets you organize rules by topic or apply them to specific file patterns.

Place your C# rules in .cursor/rules/csharp.mdc or in .cursorrules at the project root. The content is plain text with optional Markdown headings. Cursor includes it in the system context for every assistant session in your project. The Cursor rules examples guide covers the format options in detail.

The C# rules template

Copy this template and edit the sections that do not match your project. Remove sections that do not apply rather than leaving them with placeholder values.

## C# project rules

### Build and test
Build: dotnet build
Test: dotnet test --no-build
Format: dotnet format
Run: dotnet run

### Target framework
.NET 8. Do not downgrade to an older framework version.

### Nullable reference types
Enabled (<Nullable>enable</Nullable>). Every reference parameter,
return type, and field must declare its nullability. Do not use the
null-forgiving operator (!) to suppress warnings without a comment.

### Naming
Types, methods, and public properties: PascalCase.
Local variables and parameters: camelCase.
Private fields: _camelCase with underscore prefix.
Constants: PascalCase (not SCREAMING_SNAKE_CASE).
Async methods: suffix with Async.

### File and namespace
One type per file. File name matches type name.
Use file-scoped namespaces (namespace Foo.Bar;).
Namespace reflects folder structure.

### Style
Prefer expression-bodied members for single-line methods.
Prefer records for immutable data shapes.
Prefer primary constructors where the intent is clear.
Do not use var when the type is not obvious from the right-hand side.

### Dependencies
Do not add NuGet packages without noting the package name and reason.
Check for known vulnerabilities before accepting a new dependency.
Prefer packages with active maintenance and a stable release history.

### Testing
Test project mirrors the structure of the source project.
Name tests: MethodName_Scenario_ExpectedBehavior.
Use the Arrange/Act/Assert pattern with blank lines between sections.
Run dotnet test before every commit.

### Review
Do not suggest changes to generated files (*.g.cs, *.AssemblyInfo.cs).
Do not modify migrations without an explicit instruction to do so.
Summarize changes as a present-tense commit message.

What each section does

The build and test section prevents the assistant from suggesting commands that do not exist in your project. If your test command includes a project path or a filter, add it here. The target framework section stops the assistant from suggesting APIs available only in newer or older versions than the one you use.

The nullable reference types section is important for C# projects because the assistant may default to nullable-lenient patterns if it is not explicitly told the setting is on. Specifying that the null-forgiving operator requires a comment discourages the assistant from suppressing warnings without explanation.

The naming section removes ambiguity about common C# conventions that differ between teams: some use m_ prefixes for fields, some use no prefix, some put constants in SCREAMING_SNAKE_CASE. The review section tells the assistant which files to leave alone, which prevents it from proposing changes to generated output that would be overwritten on the next build.

Customize for your project type

The template above covers a general .NET library or console project. Adjust it for your specific setup.

• ASP.NET Core web API: add a section for route conventions, HTTP client usage, middleware order, and which configuration providers the project uses.
• Blazor: add a section on component naming, event callback patterns, and whether you use server-side rendering, WASM, or auto mode.
• Entity Framework: add a section on migration policy (who runs migrations, when, and how) and whether you use code-first or database-first. Note which files the assistant must not modify.
• Unit test projects: if your test project uses a specific mocking library or assertion library, name it explicitly so the assistant uses the right API.

If you work with MCP servers in C#, the MCP server C# guide covers the patterns that differ from standard ASP.NET. If you use Cursor for AI-assisted project management as well as coding, the Cursor rules for AI projects guide covers those conventions.

Keeping the rules file accurate over time

A rules file that stays accurate is more useful than a detailed one that drifts. The most common way it drifts is when a team decision changes but no one updates the file: the project moves to a newer .NET version, adopts a different test runner, or settles on a naming convention that differs from the original template. Future AI suggestions will then follow the old convention rather than the current one.

Set a brief review step into your workflow: when a team decision changes, update the rules file in the same pull request as the code change. This keeps the file honest and prevents the assistant from learning outdated guidance from an authoritative-sounding source.

A rules file is also a useful onboarding document. A new team member can read it and understand the key conventions in a few minutes. If something in the file prompts a question, that question may mean the rule needs a short explanation or the team has moved on since it was written.

When Cursor gives a suggestion that contradicts the rules file, check two things: whether the file was loaded correctly, and whether the instruction is specific enough. Vague rules leave room for interpretation. "Use PascalCase for types and methods" is specific; "follow standard C# conventions" leaves the model to decide what standard means.

What to keep in the rules file versus in fenbs

A Cursor rules file is right for stable conventions: naming patterns, build commands, framework version, testing standards. These change rarely and apply equally in every session. They belong in a checked-in file that every developer and AI assistant uses automatically.

A rules file is not the right place for project decisions that change: which tasks are in progress, which refactoring approach the team agreed on this week, which dependency was approved in last Thursday's review. Those belong in a tool that can be updated between sessions and that different coding assistants can read from a single source.

How to do this with fenbs

1. Create a free account and add your C# project.
2. Copy the template above into .cursor/rules/csharp.mdc and customize it for your project.
3. Add any architectural decisions that are still in flux as Decisions and rules in fenbs: library choices under discussion, migration policies not yet finalized, patterns the team is trialing.
4. Connect Cursor to fenbs via MCP from Integrations. At the start of a session, Cursor reads the fenbs project context alongside your rules file.
5. When a decision becomes stable enough to be a permanent rule, move it from fenbs into the rules file and record the move as a decision in fenbs with the date and reason.