20 Advanced Claude Code Tips for .NET Developers

Claude Code rewards the developer who controls its context and gives it a way to check its own work. These are the 20 tips that actually changed how I work across .NET 10 solutions: context hygiene, hooks, subagents, MCP, worktrees, and model selection, every one framed around real C# and ASP.NET Core work rather than generic advice.

Most “Claude Code tips” lists are written for no language in particular. That is fine for the basics, but a .NET developer hits problems a Python developer never sees: stale bin/obj output, dotnet build prompting on every run, an EF Core migration that should never touch production, a Roslyn-aware refactor that grep cannot reason about. The tips below are the ones that pay off specifically because you write C#.

This guide assumes you have used Claude Code before and already have a CLAUDE.md in your project. If either is new, the two reads below close the gap.

How do you actually drive Claude Code well?

The first four tips are about how you hand work to the agent. Get these right and the rest compound. Get them wrong and no amount of configuration saves you.

1. Give Claude a check it can run itself

The single highest-leverage move is handing Claude a pass/fail signal it can read without you. A coding agent stops when the work “looks done.” Without a machine-readable check, you are the verification loop, and every defect waits for you to notice it.

In .NET you already own the perfect signal: the compiler and the test runner. Tell Claude to run dotnet build and dotnet test after each change and keep iterating until both are green. The build catches the type errors an LLM invents; xUnit catches the behavior it got wrong. You turn a session you have to babysit into one you can walk away from. This one habit does more for output quality than any prompt trick.

2. Use plan mode before any multi-file change

Plan mode lets Claude research and propose an approach without touching a single file. Jumping straight to edits produces a clean solution to the wrong problem. Separating exploration from execution catches scope and approach errors while correction is still free.

Enter plan mode for anything that spans more than one file or touches code you do not know well. Claude reads the relevant types, explains the change it intends, and waits for your approval before writing anything. Skip it only when you could describe the diff in one sentence. For the full mechanics, see my dedicated walkthrough.

3. Let Claude interview you before big features

For a feature with real surface area, do not write the spec yourself. Ask Claude to interview you first: “I want to build X. Ask me questions until you have enough to write a complete spec, then save it to SPEC.md.” It surfaces the edge cases, the validation rules, and the failure modes you had not thought through. Then start a fresh session and implement against that written spec. The execution session gets a clean context anchored to a self-contained document instead of a half-remembered conversation.

4. Decompose ruthlessly into small tasks

Bundling related work because it feels efficient is a human instinct that does not transfer to the agent. A broad, interconnected task triggers context thrashing and premature “done” on the narrow case it handled first. A two-entity feature that stalls for an afternoon as one prompt often finishes in minutes when split into a handful of single-purpose tasks. Smaller scope means a tighter feedback loop and far less context pollution.

How do you manage context in Claude Code?

Context is the real bottleneck, not the model. Quality starts to degrade well before the window is full, so the developers who get the most out of Claude Code are the ones who treat context as a budget they actively spend. If you have never watched what fills it, my breakdown of a real Claude Code session shows where the tokens go.

5. Clear context between unrelated tasks

Run /clear whenever you switch to unrelated work. A simple heuristic: if you would open a new document for the task, clear the session. A polluted context, full of a failed approach and files from the last problem, actively distracts the model from the current one. After two failed corrections on the same issue, clear and rewrite the prompt with what you just learned rather than piling correction on correction.

6. Watch your context budget and compact early

You cannot manage what you cannot see. Run /context to see what is consuming the window, and set up a status line that shows context percentage, cost, and branch at all times. Compact at a natural breakpoint while the session is still healthy, not when Claude starts forgetting earlier instructions. Compacting late produces a worse summary, because the session is already overloaded when it tries to summarize itself. For very long jobs, have Claude write progress to a Markdown file, then /clear and resume from that file.

7. Push exploration into subagents

Subagents run in their own context window and return only a summary, which keeps your main conversation clean. When Claude greps and reads a codebase directly, every file lands in your window and crowds out the actual task.

Delegate the search instead: “use a subagent to find every implementation of IOrderProcessor and report back.” The subagent burns its own context on the file dumps; your main session sees a tidy answer. The built-in Explore subagent runs on Haiku and is read-only, so it is both cheap and safe for codebase reconnaissance on a large solution. When a job needs several specialists working together, the same idea scales up to agent teams.

8. Keep CLAUDE.md lean and .NET-specific

Every token in CLAUDE.md loads into every conversation, so a bloated file does double damage: it wastes context on unrelated work and buries the rules that matter under noise. For each line, ask whether removing it would cause a real mistake. If not, cut it.

Encode the things Claude cannot infer: your target framework (.NET 10 / EF Core 10), .slnx over .sln, Scalar over Swagger, your architecture, your response-shape conventions. Move situational depth into skills, which load on demand, and split long rule sets with @-imports. When Claude keeps ignoring a rule, run /memory to list exactly which instruction files are loaded and open them. The rule is usually buried in a file that grew too long.

Configure Claude Code once and stop babysitting

These tips move repeated decisions out of your hands and into version-controlled configuration. Set them up once per project and the friction disappears for everyone on the team.

9. Pre-approve safe .NET commands, gate the dangerous ones

Approving dotnet build for the hundredth time is not security, it is noise, and noise trains you to rubber-stamp. Use the permissions block in .claude/settings.json to allow the commands you trust and route the dangerous ones to an ask list so they always prompt. The trailing :* matches the command plus any arguments.

{
  "permissions": {
    "allow": [
      "Bash(dotnet build:*)",
      "Bash(dotnet test:*)",
      "Bash(dotnet format:*)"
    ],
    "ask": [
      "Bash(dotnet ef database update:*)"
    ]
  }
}

Now routine builds and tests never prompt, but a schema change against the database always stops for a human to confirm. Use the deny list instead for commands Claude should never run at all. Commit the file and the whole team inherits the same guardrails.

10. Auto-format every edit with a hook

A line in CLAUDE.md that says “always run dotnet format” is advisory, and Claude will skip it under load. A hook is deterministic and runs every time. Add a PostToolUse hook that matches Write|Edit, reads the edited file path from the JSON on its stdin, and runs the formatter on just that file.

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          { "type": "command", "command": "jq -r '.tool_input.file_path' | xargs -I{} dotnet format --include {}" }
        ]
      }
    ]
  }
}

That removes a whole class of “Claude forgot to format” corrections and frees up the CLAUDE.md lines you would have spent asking for it.

11. Gate at commit time, not mid-edit

Blocking Claude in the middle of an edit derails its reasoning. Blocking at submission forces a clean finish-then-verify loop. Use a hook on git commit (or a Stop hook) that runs your tests and blocks the turn until they pass. Make the hook exit with code 2 to feed the failure back to Claude as something it must fix, rather than a generic error it ignores. The agent finishes its thought, then gets held accountable before anything lands.

12. Turn repeatable .NET workflows into skills

The boring, repeatable procedures are exactly what skills are for: scaffolding a vertical slice, running an EF Core migration the way your team does it, a pre-PR verification pass. A skill lives in one version-controlled file, invokes with a slash command, and loads its full body only when you call it, so it costs almost nothing until used. Note that Claude Code now merges custom slash commands into skills, so a skill is the format to reach for when you want a reusable command.

13. Sandbox the session to kill permission prompts

If approval fatigue is pushing you toward bypassing permissions entirely, reach for /sandbox instead. It runs the Bash tool inside OS-enforced filesystem and network isolation, so most commands execute without a prompt while genuinely risky actions stay contained. Anthropic reports this cuts permission prompts by roughly 84% in their own use. It is the safe version of “stop asking me,” and it is a far better answer than disabling permission checks across the board.

Give Claude real .NET senses

By default Claude reads your code as text. These tips give it a semantic understanding of a C# solution and stop it from inventing APIs that do not exist.

14. Add a Roslyn-based MCP server for semantic navigation

A code-intelligence MCP server lets Claude query your solution through Roslyn instead of grepping files. Asking “where is this interface implemented” through a semantic find_references call costs a fraction of the tokens that reading and scanning files does, and it returns exact answers instead of text matches.

This is the Model Context Protocol (MCP), an open standard for connecting external tools to the agent. A Roslyn server exposes operations like find symbol, find references, and diagnostics, so Claude navigates a large solution the way Rider does. My dotnet-claude-kit ships exactly this kind of server.

15. Add Context7 for live docs, but cap your servers

A coding agent with no access to current documentation hallucinates package APIs: methods that do not exist, signatures that changed two versions ago. The Context7 MCP server pulls real, version-pinned docs into context and grounds Claude in the actual ASP.NET Core and EF Core 10 surface. That kills a whole category of “looks right, will not compile” errors.

The caveat: every connected MCP server injects its tool definitions into every context window, even when unused. Keep the total to three or four. A pile of servers you rarely call can quietly eat a large slice of your working budget before you type a word.

16. Reference your type system explicitly in prompts

Vague prompts get plausible but wrong code. “A function that processes orders” leaves Claude to invent a shape. “A method that accepts an Order entity and returns a ProcessingResult” pins it to your actual domain model. Naming concrete types, interfaces, and the data shape you expect removes ambiguity and cuts the compile-and-refactor cycles that eat your time. Your strong type system is an advantage here. Use it in the prompt, not just the code, and lean on the rest of my prompt engineering tips for .NET to sharpen the wording further.

17. Watch for compilation amnesia

A sharp one specific to compiled languages: Claude often runs tests against a stale binary because it skipped the rebuild, then chases a bug that does not exist while you both burn tokens. When test results make no sense, suspect the build before the logic. The durable fix is to bake dotnet build into the same hook that runs your tests, so the compiler output is always current and the agent never reasons about a binary that no longer matches the source.

Orchestrate and scale your work

The last tips are about running Claude Code at the level of a whole feature or a whole codebase, not a single file.

18. Run parallel work in git worktrees

Two Claude sessions editing the same checkout collide, and in .NET they fight over bin and obj on top of the source. Git worktrees give each session its own files on disk while sharing history. Start one with claude --worktree feature-x and it creates an isolated worktree and branch in a single step. Now one session can build and test feature A while another refactors feature B, with conflicts surfacing only at merge time, exactly like a team of developers would.

19. Fan out headless runs for big mechanical jobs

For a large, repetitive change, a migration sweep from .NET Framework to .NET 10, do not ask one interactive session to juggle hundreds of files. Generate the file list, then loop a headless claude -p "..." call over each file, giving every file a fresh isolated context. Test the prompt on two or three files, refine it, then run it at scale. One note worth knowing: as of mid-2026, headless and SDK usage bills against a separate Agent SDK credit pool rather than your interactive subscription, so budget for it if you automate this in CI.

20. Match the model and effort to the task

Do not pay for reasoning you do not need. Claude Opus 4.8 is the default on Max and API plans, while Pro plans default to Sonnet 4.6, and Opus is the right tool for architecture and hard debugging. Routine work, scaffolding a DTO, wiring an endpoint, does not need it. Switch to Sonnet with /model for balanced day-to-day work, and route a Haiku subagent at pure search. Pair that with /effort: high is the default on Opus 4.8, so drop to medium or low to move faster on routine edits, and save xhigh for the genuinely hard problems.

My take: which of these matter most

If you only adopt three, make them the verification loop (tip 1), aggressive context hygiene (tips 5 to 8), and one deterministic hook (tip 10). Those three are the difference between an agent you supervise keystroke by keystroke and one you can hand a real task. Everything else is acceleration on top of that foundation.

The mistake I see most often is reaching for configuration before discipline: a dozen MCP servers, an elaborate set of custom commands, a 300-line CLAUDE.md, all bolted onto a workflow that still skips plan mode and never gives Claude a way to check its own work. Fix how you hand off the task first. Then automate the parts that repeat.

Key Takeaways

• Verification is the top lever. Wire dotnet build and dotnet test as a loop Claude runs itself, and quality jumps without more supervision.
• Context is the real constraint. Clear between tasks, compact early, push research into subagents, and keep CLAUDE.md lean.
• Hooks beat instructions. A PostToolUse dotnet format hook and a commit-time test gate are deterministic where CLAUDE.md is only advisory.
• Give Claude .NET senses. A Roslyn MCP server and Context7 turn text-level guessing into semantic navigation against your real API surface.
• Scale with worktrees and the right model. Parallel sessions in isolated worktrees, Opus for hard reasoning, Sonnet and Haiku for the rest.

FAQ

Wrapping Up

None of these tips are about clever prompts. They are about control: controlling what Claude sees, giving it a way to check itself, and moving the repeatable parts into configuration the whole team shares. Start with the verification loop and context hygiene, add hooks and a Roslyn MCP server as you go, and Claude Code stops being a chat box and starts being a teammate you can actually delegate to.

If you want the .NET-aware setup that ties a lot of this together, the dotnet-claude-kit bundles the skills, agents, and Roslyn server I use daily, and the Claude Code for .NET Developers course walks through the full workflow.

Happy Coding :)