Set Up Claude Code for .NET Like You Mean It

In Part 1 we drew the map: the loop, the models, the app we're building. Today Claude Code goes onto your machine, learns your project's house rules, and makes its first change to real code — one you'll read, run, and commit like any other. Setup done properly is the difference between an AI pair you trust and one you babysit.

Install and sign in

Two routes, same destination. If you have Node.js, the command-line tool is one line:

npm install -g @anthropic-ai/claude-code

If you'd rather skip the terminal, download the desktop app for Mac or Windows from Anthropic instead — same brain, friendlier chrome. Either way, the first launch asks you to sign in with your Anthropic account; a paid Claude plan or API billing both work. Then open your project folder — with the CLI that's just:

cd MyApp
claude

That's the whole install. The part that matters is what you do in the first five minutes.

The first conversation

Start with something read-only and harmless, in any .NET project you have lying around:

Give me a tour of this solution. What does it do, how is it
structured, and what would you want to know before changing it?

Watch what happens: it lists your directories, opens your .csproj files, reads your Program.cs — by itself, telling you what it's doing as it goes — and comes back with a summary that's usually startlingly accurate. This is the moment the chat-versus-agentic distinction from Part 1 stops being abstract. Nobody pasted anything. It's a chat window with hands.

CLAUDE.md: the house rules

Every project you use Claude Code in deserves a file called CLAUDE.md at the repository root. It's a plain Markdown file of standing instructions, loaded automatically at the start of every session — the things you'd otherwise repeat in every conversation: how to build, how to test, what your team's style is, what's off-limits. Here's a complete, honest example for a .NET solution:

# MyApp — notes for Claude

## Commands
- Build: dotnet build MyApp.sln
- Test:  dotnet test MyApp.sln
- Run:   dotnet run --project src/MyApp

## Code style
- .NET 10, C# latest; nullable reference types stay enabled.
- File-scoped namespaces; one public type per file.
- Full names over abbreviations (appointment, not appt).
- Async methods end in Async and are awaited — never .Result or .Wait().

## Rules
- Never edit files under Migrations/ by hand — always use dotnet ef.
- Ask before adding a NuGet package, and say why it earns its place.
- Ask before deleting or renaming anything public.
- Small steps: for anything touching more than three files, propose
  a plan first and wait.

## Verify your work
- After any change: dotnet build, then dotnet test. Both must pass
  before you call a task done.

Read it as three kinds of instruction. The commands section lets the AI verify its own work — that's the review loop from Part 1 running automatically. The style section saves you from correcting the same preferences forever. And the rules section is where you encode scar tissue: "never touch Migrations by hand" and "ask before adding packages" are cheap sentences that prevent expensive afternoons. Commit this file; it's part of the project now, and it will grow as the AI surprises you.

Permission rails: start strict

By default, Claude Code asks before it acts: before editing a file it shows you the diff and waits; before running a command it shows you the command and waits. You can loosen this — allow specific tools permanently, allow whole categories, or go all the way to an auto-accept mode where it works through a task without stopping. Resist the temptation to loosen it on day one.

Our advice, and how this whole series was actually built: start strict, loosen as trust grows. In week one, approve everything by hand and read every diff — that's how you learn the tool's habits, good and bad. Later you'll happily let dotnet build and dotnet test run without asking, because they're how the AI checks itself. The golden rule never loosens, though: small steps, and a human reads every diff before it lands. That's the review box in Part 1's loop diagram, and it is load-bearing.

Your first change, end to end

Time to complete the loop once, deliberately small. If you don't have a throwaway project handy, make one:

dotnet new console -n HelloClaude
cd HelloClaude
git init
claude

Now a tiny, verifiable ask — one where you can tell at a glance whether it worked:

In Program.cs, change the greeting to include the current time,
formatted like 14:32. Don't add any packages.

Claude proposes an edit and shows you the diff — a couple of changed lines in Program.cs. Read it. Actually read it: is it using DateTime.Now the way you'd expect? Is the format string right? This takes ten seconds on a change this size, which is precisely why we keep changes this size. Approve it, then verify with your own hands:

dotnet run

It prints the greeting with the time. The loop is closed — prompt, review, run — except for the last box: commit. And here we introduce the habit this series is built on.

The commit habit: record the prompt

A commit message's subject says what changed. For AI-assisted work, the body should record the prompt that produced it:

git add .
git commit -m "Show the current time in the greeting" -m "Prompt: In Program.cs, change the greeting to include the current
time, formatted like 14:32. Don't add any packages."

Why bother? Because six months from now, the prompt is the best documentation of intent you'll ever have — better than the diff, because it says what you asked for, not just what you got. It keeps you honest about what was AI-authored. And it makes your history reproducible in a way plain commits never were. This is the series' signature convention: in the companion repository, every single commit message contains the prompt that produced it — the history is the tutorial. (If commit messages are new territory, our Git series covers the art of messages that explain why.)

Tools installed, rails set, habit formed. In Part 3 we start ClinicLive for real — and the first thing we build isn't code. It's a one-page spec, written by making the AI interview us.