Claude Code Commands Every .NET Developer Should Use

After using Claude Code in .NET code bases, I’ve built up a set of commands I consider essential. I’m sharing them here because some took me embarrassingly long to find, and a couple I only discovered after watching others use Claude Code in live workshops. If you’re using it in a .NET environment, these are worth knowing.

Project Setup

/init: Read your solution before you type a single prompt

Run /init once, at the start of every new project. Claude reads your .sln, every .csproj, your target frameworks, and your folder layout, then generates a starter CLAUDE.md file at the repo root.

The generated file is a starting point, not a finished document. Edit it immediately. Add your DI conventions, your async rules, the patterns you want enforced, and the patterns you want banned. The time you spend here pays back across every session that follows.

What to add for any .NET project:

- Async suffix required on all async methods
- Use primary constructors (C# 12+)
- DI lifetimes: repositories = Scoped, services = Scoped, caches = Singleton
- Prefer Result<T> over throwing exceptions in the application layer
- Target net8.0: do not suggest APIs unavailable before net8.0
- Logging via ILogger<T> only: no static loggers, no Console.WriteLine

If you skip /init and those rules are not written down anywhere, Claude will make reasonable guesses. Sometimes those guesses are wrong in ways that are annoying to unpick three files later.

/memory: Edit CLAUDE.md without leaving the session

/memory opens your CLAUDE.md directly for editing. Use it when a team convention surfaces mid-session that was not in the original file.

I reach for it most often when Claude does something technically correct but wrong for the codebase, such as introducing IOptions<T> in a project that binds config differently, or writing a service with a transient lifetime where the team uses scoped by default. Write the rule, save, continue. It will not make the same call again in that session or any future one.

# <rule>: Pin a convention in seconds without opening a file

Prefix any line with # and Claude treats it as a persistent memory note. It writes directly to your memory store and survives session ends.

# use primary constructors throughout this refactor
# prefer Result<T> over exceptions in the application layer
# target net8.0: flag anything that requires net9.0

This is faster than /memory when you just need to lock in one thing and keep moving. The difference from CLAUDE.md is intent: CLAUDE.md is for standing project conventions, # notes are for decisions made during a specific task that you want carried forward. Use both.

Context Control

@<file> / @*.csproj: Load exactly what Claude needs, without a round trip

Prefix a file path in your prompt with @ and Claude Code injects that file’s content directly into your message before sending anything to the model. Glob patterns work too.

@src/Domain/Orders/IOrderRepository.cs add a GetByCustomerId method consistent with existing signatures
@src/Api/Api.csproj check if FluentValidation is already referenced before adding it
@**/*.csproj confirm all projects target net8.0

Without @, if Claude needs a file it has to make a Read tool call: the model requests the file, the tool executes, the result comes back, then the model continues. That is an extra round trip through the inference engine, and it happens mid-response. With @, the content is already in the initial message. No tool call, no latency hit, and you know exactly what Claude is reading before it starts rather than finding out in the tool call trace.

On a large solution this matters beyond just speed. Claude reasoning about your Order aggregate while 40 other service files are in context produces noisier output than Claude reasoning about it with just the relevant interface and its dependencies loaded. Be deliberate about what you load.

/context: See exactly what Claude is working with

/context prints a summary of everything currently loaded in the session—files read, memory notes, CLAUDE.md contents, and how much of the context window is consumed.

It is most useful right before a complex prompt. If you are about to ask Claude to redesign a service boundary and /context shows it still has three unrelated controller files from earlier in the session loaded, that is a problem worth fixing before you start. Load less, ask the question, get a cleaner answer.

Two practical uses:

Catch stale context before it causes a bad diff. If Claude confidently suggests an approach that ignores a constraint you mentioned an hour ago, run /context and check whether your CLAUDE.md rules and memory notes are still visible or whether they’ve been pushed out.

Decide whether to /compact or /clear. If /context shows you’re at 60% context usage with mostly useful content, compact. If it’s full of noise or you’re context-switching to a different bounded context, clear.

/context

No arguments. Read the output before you commit to a long session.

/clear: Reset context when switching layers or bounded contexts

/clear wipes the session context completely. Use it whenever you finish work in one layer and move to another.

After an hour in the Domain layer, Claude has a detailed mental model of your aggregates, value objects, and invariants. That context bleeds into decisions when you move to the API layer. Controllers written with that residual context tend to be too aware of domain internals, which is usually not what you want.

One bounded context per session context is a reasonable rule. /clear is how you enforce it.

/compact: Compress long sessions without losing what matters

/compact alone summarizes with whatever heuristic Claude picks. Give it explicit instructions instead:

/compact keep: decisions made, migration steps completed, current task state. discard: stack traces, EF migration output, file read contents

The signal that you need it: Claude re-reads a file it processed 30 minutes ago, or contradicts a design decision from earlier in the session. On a large feature branch where you’ve been adding endpoints, fixing validation, and tweaking EF queries across the same session, the diff noise from early iterations starts drowning out the design calls you made two hours in.

claude -c: Resume exactly where you left off

claude -c from the terminal resumes the most recent session. For a specific session, run claude --list-sessions first, then claude --resume <id>.

This is the command that makes multi-day migrations manageable. On a large framework upgrade, you do not want to re-establish context every morning. Resume, check where you were, keep going.

When NOT to resume: if the previous session hit a wrong assumption about your schema or service layer, start fresh. A session with a stale mental model of your DbContext will produce confident, wrong diffs. The cost of a clean start is lower than you think.

Code Quality

/advisor: Call a stronger reviewer on the full session

/advisor sends your entire conversation history to a more capable model and asks it to review what you are doing. No parameters. It sees every tool call, every diff, every decision made in the session.

Use it before committing to a complex approach, when something feels off but you cannot pinpoint why, or before declaring a large task done.

/advisor routes the same session context to a more capable secondary model (typically Opus) configured as a consultant, that’s what I use. When NOT to use it: simple reactive tasks where the next step is obvious from the tool output. It adds the most value on the first call, before an approach crystallises.

Shift+Tab: Force a plan before any file is touched

Shift+Tab cycles into plan mode. Claude proposes a step-by-step plan and waits. Nothing is edited until you approve.

Use this for anything that crosses more than one layer of a clean architecture project. The plan is not a yes/no prompt, it is a document you can edit. Before approving, add the constraints that are not obvious from the task description:

also verify this doesn't break the IUnitOfWork registration in Program.cs
also check whether the existing middleware registrations in Program.cs need updating

Claude incorporates those constraints before generating a single diff. Reviewing the plan takes two minutes. Reviewing a multi-file edit that missed a registration takes considerably longer.

Esc Esc: Undo the last action without losing earlier work

Double Esc rewinds the last agent action and restores the files to their previous state. Use it the moment you see something wrong: a bad LINQ rewrite, an incorrect nullable annotation, an EF query that will cause a full table scan.

It is faster than git checkout and preserves everything Claude did before the bad step. One thing it does not do: undo committed git changes. If Claude ran git commit as part of the task, you need git reset for that part.

/review: Run a structured code review before opening a PR

/review reads the current diff and checks it against a fixed set of criteria: SOLID violations, async/await correctness including sync-over-async patterns, nullable reference type handling, IDisposable and IAsyncDisposable disposal, and obvious LINQ-to-SQL performance issues.

Run it before every PR. It catches the async void event handler, the missing ConfigureAwait(false) in library code, and the repository method that forgot to dispose its DbCommand. Your human reviewer will catch those things too, but later, in a comment thread, after you have already moved on mentally.

Model and Cost

/model: Match the model to the complexity of the task

Switch models mid-session without restarting.

/model opus    # DDD design sessions, service boundary decisions, complex domain modelling
/model sonnet  # controllers, DTOs, standard CRUD, test scaffolding
/model haiku   # rename operations, null checks, boilerplate generation

Opus on a DTO scaffold is waste. Haiku on a bounded context design produces answers that are technically plausible and architecturally thin. The rule of thumb: reach for Opus when the task requires judgement about your specific domain, reach for Sonnet when it requires executing a clear instruction well.

/cost: Know what you are spending before the invoice arrives

/cost shows token spend for the current session.

Run it after a full solution read on a large .sln to calibrate what that costs. A session scoped with @ file references costs a fraction of one that loads the full solution. Once you see the numbers, you start scoping more deliberately.

Collaboration and Extension

/pr-comments: Address review feedback in-place

/pr-comments pulls open review comments from GitHub or Azure DevOps and addresses them against the current branch. Claude reads each comment, locates the file and line, and applies the change. When the reviewer’s intent is ambiguous, it asks rather than guessing.

Run it after a review round before re-requesting. Check each diff before approving. Reviewer intent and reviewer phrasing are not always the same thing, and Claude takes phrasing literally.

/agents: Run independent tasks in parallel

/agents spins up subagents for work that does not depend on a shared intermediate state.

Useful patterns on .NET projects:

• One agent generating xUnit tests for a new service while another writes the OpenAPI annotations
• One agent producing the EF Core migration script while another validates the corresponding down-migration
• One agent updating DTOs while another updates the AutoMapper profiles

Agents share no context with each other. Give each one explicit file references and a clear, bounded output expectation. If two tasks have a dependency between them, run them sequentially. Parallel agents on dependent tasks produce conflicts that take longer to fix than the time you saved.

/mcp: Connect Claude to systems beyond the filesystem

/mcp manages MCP server connections. These extend what Claude can read and act on during a session.

Useful servers for .NET and Azure work:

Vet what you add before adding it. MCP servers can execute code against live systems. An Application Insights server pointed at production is not the same risk profile as a read-only NuGet lookup.

/init on day one. /clear between layers. Everything else as needed.