30 Advanced Claude Code Tips for .NET Developers (2026)

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

Claude Code ships weekly, so a tips list goes stale fast. I re-verified every command, flag, and setting on this page against the official documentation on 6 August 2026, and rewrote the parts that had changed. Tips 21 to 30 cover features that did not exist when I first published this.

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.

How hard the check gates the stop is a separate decision, and there are four rungs on that ladder:

• In the prompt. Ask Claude to run the check and iterate in the same message. Works today, on any task, with no setup.
• Across the session. Set the check as a /goal condition (tip 21) and a separate evaluator re-checks it after every turn.
• As a deterministic gate. A Stop hook runs your check as a script and blocks the turn from ending until it passes. Worth knowing the escape hatch: Claude Code overrides the hook and ends the turn after 8 consecutive blocks, so a badly written gate cannot trap a session forever.
• By a second opinion. A verification subagent gets a fresh model to review the result, so the agent that did the work is not the one grading it.

Each rung trades setup effort for attention. Whichever you pick, ask for evidence rather than an assertion: the actual dotnet test output, not “all tests pass.” Reading the output is faster than re-running the suite yourself, and it is the only thing that works for a session you were not watching.

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.

One shortcut most people miss: when the plan appears, press Ctrl+G to open it in your text editor. You get to delete the two steps you disagree with and tighten the wording, rather than typing a paragraph of corrections into the terminal and hoping the revision lands. Editing a plan directly is far faster than negotiating one.

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 is read-only, with Write and Edit denied, which makes it safe to point at a large solution.

One detail changed recently and it affects your bill. Explore used to always run on Haiku. Since v2.1.198 it inherits your main conversation’s model instead, capped at Opus on the Claude API. So if you are working in Opus, your codebase searches are now running on Opus too. If you would rather keep reconnaissance cheap, define your own subagent named Explore in .claude/agents/ with model: haiku in its frontmatter, which overrides the built-in:

---
name: Explore
description: Fast read-only codebase search
tools: Read, Grep, Glob
model: haiku
---
Search the solution and report only what was asked for. Do not modify files.

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.

A useful test from the official guidance: for every line, ask whether removing it would cause Claude to make a mistake. Bash commands it cannot guess, style rules that differ from the defaults, and environment quirks earn their place. Standard C# conventions it already knows, file-by-file descriptions of your solution, and anything it can learn by reading the code do not.

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.

One caveat that bites this audience specifically: jq and xargs are not on a stock Windows box. If you run Claude Code in PowerShell without them, the hook fails quietly and you get no formatting at all while believing you do. Either run inside Git Bash or WSL 2, install jq with winget install jqlang.jq, or rewrite the command in PowerShell and read the JSON from stdin there. Test it once by editing a file and checking that the formatter actually ran.

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.

For a workflow with real side effects, a database reset or a deployment, add disable-model-invocation: true to the skill’s frontmatter. Claude then cannot decide to run it on its own; only you can, by typing the command. That single line is the difference between a convenience and a liability. If you want a worked example, I walked through a skill that scaffolds a .NET architecture end to end.

13. Kill permission prompts with auto mode, not bypass

If approval fatigue is pushing you toward --dangerously-skip-permissions, there are two better answers and you can run both.

Auto mode is the one to reach for first. A separate classifier model reviews each action before it runs, so routine work proceeds while genuine escalation gets blocked - production deploys, force pushes, curl | bash, git reset --hard where uncommitted work would be lost. It is available on every plan, though it does have a model floor: recent Opus, Sonnet, and Fable models qualify, while older ones and Haiku do not. If it never appears for you, that is the usual reason. Cycle to it with Shift+Tab, or make it your default in ~/.claude/settings.json:

{
  "permissions": {
    "defaultMode": "auto"
  }
}

That has to live in your user settings. Claude Code ignores defaultMode: "auto" in a project’s .claude/settings.json on purpose, so a repo you cloned can’t quietly grant itself the loosest mode.

The part most people miss is that you can steer the classifier in plain English. Tell Claude “don’t push until I’ve reviewed this” and it treats that as a block signal for the rest of the session, overriding rules that would otherwise allow the push. It re-reads that boundary from the transcript on every check, though, so a compaction that drops the message drops the boundary. For a guarantee that survives, write a permissions.deny rule instead.

Sandboxing is the complementary layer: /sandbox runs the Bash tool inside OS-enforced filesystem and network isolation, so risky commands are contained rather than merely judged. Anthropic reports roughly an 84% cut in permission prompts from it. One caveat for this audience: sandboxing isn’t supported on native Windows. If you want it, run Claude Code inside WSL 2.

Either beats disabling permission checks across the board. Bypass mode offers no protection against prompt injection, and it belongs in a container, not on your dev box.

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, and measure the real server cost

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.

Worth correcting the advice you will still see repeated everywhere: MCP tool definitions are now deferred by default, so only tool names enter the context window until Claude actually reaches for a specific tool. The old rule that every connected server floods your context with full schemas is out of date. That does not make servers free, though. Names, connection overhead, and the extra choices they hand the model all cost something. Run /context to see what your servers actually consume, and /mcp to switch off the ones you are not using.

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, under .claude/worktrees/feature-x/ on a new worktree-feature-x branch. 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.

The gotcha that wastes an afternoon: a worktree is a fresh checkout, so none of your gitignored files come with it. In a .NET repo that means appsettings.Development.json, your local .env, and anything else you deliberately kept out of git simply is not there. The session starts, the build succeeds, and the app dies at runtime on a missing connection string. Fix it once with a .worktreeinclude file at your project root, which uses gitignore syntax and copies matching gitignored files into every worktree Claude creates:

appsettings.Development.json
appsettings.Local.json
.env

Three more things worth setting up the first time:

• Add .claude/worktrees/ to .gitignore, or every worktree shows up as untracked noise in your main checkout.
• New worktrees branch from your remote default branch, not your current work. If you want them to carry your unpushed commits instead, set "worktree": { "baseRef": "head" } in settings.
• Subagents can get their own worktrees too. Add isolation: worktree to a custom subagent’s frontmatter and it runs in an isolated checkout, which is what makes a parallel mechanical refactor safe.

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.

for file in $(cat files.txt); do
  claude --bare -p "Migrate $file to the new logging abstraction. Return OK or FAIL." \
    --allowedTools "Edit,Bash(dotnet build:*)"
done

Two flags carry that command. --allowedTools restricts what Claude can touch, which matters a lot when nobody is watching. --bare skips auto-discovery of hooks, skills, plugins, MCP servers, and CLAUDE.md, which both cuts startup time and makes the run reproducible: a teammate’s personal hook in their home directory cannot change the result. The docs now call --bare the recommended mode for scripted and SDK calls, and it is slated to become the default for -p. Note that bare mode does not read your subscription login, so set ANTHROPIC_API_KEY for it. For a genuinely locked-down CI run, add --permission-mode dontAsk, which denies anything outside your allow rules instead of prompting a terminal nobody is reading.

A correction worth flagging, since I had this wrong here for two months. Anthropic announced in mid-2026 that Agent SDK and claude -p usage would move to a separate monthly credit pool instead of counting against your plan’s limits. That change was paused before it took effect, and the support article now opens by saying so plainly: for now, nothing has changed. Headless usage still draws on your normal plan limits. Check that page before you budget a large automated sweep, because this is clearly a policy Anthropic intends to revisit.

20. Match the model and effort to the task

Do not pay for reasoning you do not need. The current lineup is Fable 5 at the top, then Opus 5, Sonnet 5, and Haiku 4.5, and your plan decides which one you land on by default - run /model to see. Think in tiers rather than version numbers, because the names change every few months and the shape of the advice does not. 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, which controls how hard the model thinks independently of which model you picked. The levels run low, medium, high, xhigh, and max, with ultracode sitting above them as a combination of xhigh and automatic workflow orchestration. Which levels you see depends on the model. Drop to low or medium to move faster on routine edits and save the top of the range for genuinely hard problems. Effort is the dial most people forget exists, and it changes cost and latency more than switching models does.

How do you let Claude Code run unattended?

The first twenty tips assume you are sitting there. These five are about handing Claude a job and walking away without losing control of it. They all shipped after I first published this list.

21. Set a finish line with /goal

/goal sets a completion condition, and a separate model checks after every turn whether that condition holds. If it does not, Claude starts another turn instead of handing control back to you. The goal clears itself once the condition is met.

This is the missing piece in tip 1. A prompt asking Claude to “keep going until tests pass” relies on the same model that wrote the code to judge whether it worked. A goal puts a fresh evaluator in that seat.

/goal every project builds with dotnet build and all tests in tests/Api.Tests pass

Setting a goal starts a turn immediately, so you do not send a separate prompt. A ◎ /goal active indicator shows how long it has been running, and /goal with no argument reports turns spent, tokens burned, and the evaluator’s most recent reason. /goal clear stops it.

Three things determine whether a goal actually works:

• Write a condition Claude’s own output can prove. The evaluator reads the transcript. It does not run commands or read files itself. “All tests in tests/Api.Tests pass” works because Claude runs the suite and the result lands in the conversation. “The code is production ready” does not.
• Bound it. Add a clause like or stop after 20 turns, otherwise a goal that can never be satisfied will keep spending tokens.
• Pair it with auto mode. A goal does not change permissions, so in the default mode Claude still stops to ask before running your test command. That defeats the point.

It needs Claude Code v2.1.139 or later, and a workspace you have accepted the trust dialog for, because the evaluator runs through the hooks system.

22. Fan out a real migration with /batch and workflows

Tip 19’s bash loop still works, but there is now a native path for the same job. /batch orchestrates large-scale changes across a codebase in parallel, and dynamic workflows go further: Claude writes a JavaScript script that spawns and coordinates subagents, and a runtime executes it in the background while your session stays responsive.

The distinction that matters is who holds the plan. With subagents, Claude decides turn by turn what to spawn next and every result lands in its context window. With a workflow, the script holds the loop, the branching, and the intermediate results, so your context only ever sees the final answer. That is what lets one run cover hundreds of files.

Trigger one by asking in plain English, or by putting ultracode in your prompt:

use a workflow to migrate every controller under src/Api/Controllers to
Minimal API endpoints, working on each file in its own isolated copy,
then verify each one still compiles

Watch it with /workflows, which shows each phase, its agent count, and its token spend, and lets you pause or stop the run. When a run does what you wanted, press s to save its script as a reusable command.

Two limits worth knowing before you start: 16 concurrent agents and 1,000 agents total per run. And a real caution, because this is the most expensive feature on this page: a workflow can burn an order of magnitude more tokens than doing the same work in conversation. Run it on one directory before you run it on the solution. The default size guideline aims for under 15 agents, and /config lets you change that.

23. Get an adversarial review before you call it done

The longer Claude works unattended, the more you need something other than Claude’s own judgement to tell you it went well. Run /code-review, a bundled skill that reviews the current diff for correctness bugs in a fresh subagent context. Because the reviewer never saw the reasoning that produced the change, it evaluates the result on its own terms rather than defending it.

For a plan-conformance check rather than a bug hunt, write the prompt yourself and name what counts as a finding:

Use a subagent to review the diff against SPEC.md. Check that every
requirement is implemented, the listed edge cases have tests, and nothing
outside the task's scope changed. Report gaps, not style preferences.

That last sentence earns its place. A reviewer asked to find problems will find some whether or not they exist, and chasing every one produces defensive code and tests for cases that cannot happen. Tell it to flag only what affects correctness, and treat the rest as optional.

24. Rewind instead of starting over

Tip 5 says to clear the session after two failed corrections. That still holds, but /rewind is usually the better move: press Esc twice, pick a checkpoint, and restore the conversation, the code, or both. You rewind to just before the approach went wrong and take the other branch with the context intact, rather than losing the good half of the session along with the bad.

Every prompt you send creates a checkpoint, and they are saved with the conversation, so you can close your terminal, resume days later, and still rewind. This changes how you should prompt. Rather than carefully planning every move, tell Claude to try the risky refactor. If it does not work out, roll it back and try the other one.

25. Know exactly what checkpoints do not cover

Here is the sharp edge of tip 24, and it catches .NET developers harder than most: checkpoints only track changes Claude made through its file-editing tools. Anything that happened through a Bash command is not captured.

Think about how much of a .NET workflow runs through the shell. dotnet ef migrations add, dotnet new, dotnet format, dotnet add package, any script that rewrites a .csproj. Claude runs those as commands, so a /rewind that cleanly reverts every C# file it edited will leave a new migration folder, a modified lock file, and a package reference exactly where they were.

Treat checkpointing as an undo for the conversation, not for your working tree. Git is still the thing that protects you. Commit before you let Claude attempt anything structural, and git status after a rewind so you can see what the rewind did not touch.

Which autonomy tool for which job

Five features on this page all claim to make Claude keep working. They are not interchangeable, and picking the wrong one is how you end up with a runaway token bill or a loop that quietly stops early. The real question is who holds the plan and what decides to stop.

My rule of thumb: /goal for a feature, a workflow for a migration, a Stop hook for anything the whole team must not skip. Everything else is a variation on those three. If you are reaching for a workflow to change six files, you have picked the expensive tool for a cheap problem.

Session control most .NET developers never turn on

Five smaller ones. Each takes under a minute to adopt and removes friction you have probably stopped noticing.

26. Ask side questions with /btw

Mid-task you want to know what IAsyncEnumerable does to your response buffering, or which package version you are on. Asking normally puts the question and the answer into the conversation forever, where it competes with the actual task for attention.

/btw answers in a dismissible overlay that never enters conversation history. The context cost is zero. Once you have this, the instinct to open a second terminal for quick lookups goes away.

27. Reclaim context surgically instead of compacting everything

/compact is all-or-nothing and /clear throws the session away. There is a middle option most people never find: press Esc twice, select a message checkpoint, and choose Summarize from here or Summarize up to here.

The first condenses everything after that point while keeping earlier context intact. The second condenses the earlier messages and keeps recent ones in full. That second one is the useful one after a long debugging detour: you keep the fix you just landed in full detail and compress the forty tool calls it took to get there.

You can also steer normal compaction from CLAUDE.md. A line like "When compacting, always preserve the full list of modified files and the exact test command" survives into every summary, which stops the classic post-compaction failure where Claude forgets how to run your tests.

28. Add a second project with --add-dir, not a restart

A .NET solution rarely lives in one folder. When Claude needs the API project and a shared library that sits outside your working directory, --add-dir grants access to the extra folder without moving the session. /cd moves the session’s working directory mid-conversation, which is the right call when you have genuinely changed focus.

Both beat the alternative of quitting and relaunching, which throws away the prompt cache you have spent the session building.

29. Name your sessions and treat them like branches

Claude Code saves conversations locally, so a task spanning two days does not need re-explaining. claude --continue picks up the most recent session and claude --resume gives you a list to choose from.

The habit that makes this useful is naming them. Run /rename and give the session a name like orders-endpoint-refactor. Now each workstream has its own persistent context and you can find it a week later, instead of squinting at a list of timestamps trying to remember which one held the EF Core work.

30. Keep your personal rules out of the team’s CLAUDE.md

Everything in CLAUDE.md is committed and loads for everyone. But some rules are genuinely yours: the local connection string you use, a preference for how much explanation you want, a note about the quirk in your machine’s setup.

Put those in CLAUDE.local.md at the project root and add it to .gitignore. You also have ~/.claude/CLAUDE.md for rules that should apply to every project you touch. Three levels, three audiences: the team’s conventions, your project-specific notes, and your global preferences. Most bloated CLAUDE.md files are bloated because all three got dumped into one.

A few more worth a bookmark

--safe-mode deserves a sentence of its own. When Claude starts behaving oddly, a session with all customizations disabled answers “is it me or is it my config?” in about thirty seconds. That question used to cost a lot more.

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.

If you are starting from nothing on a .NET repo today, this is the order I would turn things on. Each step only makes sense once the one before it is in place:

1. A lean CLAUDE.md with your target framework, your architecture, and the exact build and test commands. Ten minutes, and it improves every session afterwards.
2. A permissions allow list for dotnet build, dotnet test, and dotnet format, with dotnet ef database update on the ask list. Kills the approval fatigue that makes you rubber-stamp.
3. Plan mode as a habit for anything touching more than one file.
4. One PostToolUse format hook. Deterministic where a CLAUDE.md line is only advisory.
5. A commit-time test gate, so nothing lands without the suite passing.
6. A Roslyn MCP server, once the discipline above is real and the bottleneck has become how Claude navigates your solution.
7. /goal and worktrees, when you want to hand over whole features rather than single changes.

Most people invert this and start at step 6 or 7. Configuration on top of a workflow that never verifies anything just produces wrong answers faster.

Troubleshooting common Claude Code problems in .NET

The five failures I see most often on .NET projects, and what actually fixes each one.

Tests fail against code that looks correct. Claude ran the suite against a stale binary because it skipped the rebuild. Suspect the build before the logic, and bake dotnet build into the same hook that runs your tests so the compiler output is always current. This is tip 17, and it is the single most common wasted debugging session in .NET.

The app dies at runtime inside a worktree, but works in your main checkout. A worktree is a fresh checkout, so your gitignored appsettings.Development.json and local secrets are not there. Add a .worktreeinclude file as described in tip 18.

Your formatting hook never runs and you get no error. jq and xargs do not exist on a stock Windows install, so the hook fails silently in PowerShell. Run in Git Bash or WSL 2, install jq, or rewrite the hook command in PowerShell.

/rewind reverted the C# files but left a migration behind. Checkpoints only cover Claude’s file-editing tools, not Bash commands. dotnet ef migrations add ran through the shell, so it survives the rewind. Check git status after any rewind, and see tip 25.

Claude ignores a rule that is clearly written in CLAUDE.md. The file is almost certainly too long and the rule is buried. Run /memory to see exactly which instruction files loaded, then prune. If the rule must never be skipped, convert it from an instruction into a hook, since instructions are advisory and hooks are not.

/sandbox does nothing on your machine. Sandboxing is not supported on native Windows. Run Claude Code inside WSL 2 if you want OS-enforced isolation.

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.
• /goal closes the unattended loop. A separate model checks your condition after every turn, so completion is judged by something other than the agent that did the work.
• 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, plus .worktreeinclude so your local config actually comes with them.
• Checkpoints are not git. /rewind covers Claude’s file edits, never the dotnet commands it ran through the shell.

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.

The tooling moves fast enough that half of tips 21 to 30 did not exist when I published the first twenty. The underlying advice has not moved at all: give the agent a way to check its own work, spend context deliberately, and make the rules that matter deterministic. Every feature Anthropic ships lands somewhere on those three, which is a decent filter for deciding what is worth your time.

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 my Claude Code for .NET Developers course (linked above) walks through the full workflow.

Happy Coding :)