Cursor rules for .NET engineers

Generic Cursor prompts treat every C# repo like a tutorial sample. Senior teams need AI coding rules that load only where they apply, plus architectural persistence for Cursor so decisions survive new chats. This page is the map; the Agentic Architect kit is the implementation.

What "Cursor rules for .NET" actually means

Cursor reads .mdc files from .cursor/rules/. When you scope a rule to Infrastructure/**/*.cs, EF Core guardrails fire on data access, not on your API layer. That is the difference between a 2,000-token preamble on every prompt and a sharp, file-aware assistant.

For .NET specifically you want separate rules for DI lifetimes, Result<T> discipline, EF reads, and layer boundaries. One monolithic "be a good architect" rule does not survive a real MediatR pipeline.

Architectural persistence for Cursor

Chat history is not memory. Persistence means a committed LEARNING_LOG.md plus a rule (persistence.mdc) that tells the agent to hydrate the log at session start and append ADR-style entries when you make non-obvious calls.

Example entry after you reject a suggestion:

## ADR-009 — Order queries
- Read paths use AsNoTracking via IOrderReadRepository.
- No Include deeper than 2 levels on list endpoints.

Next morning, new chat, same repo: the model reads entry #9 before touching OrderRepository.cs.

Circuit breaker for hallucination loops

When Cursor invents APIs that do not exist, most engineers become the circuit breaker manually. bug-breaker.mdc automates that: after repeated failed edits on one file, generation stops and the agent must re-read real sources.

Related essays (free)

• The Context Tax
• Stop Cursor AI drift on .NET
• EF Core patterns with Cursor
• Cursor vs Rider for .NET

---