Claude Code Prompts for .NET Developers - A Copy-Paste Library for Every Workflow Stage

This is a copy-paste library of 11 Claude Code prompts covering the entire .NET development workflow: brainstorming, tech research, architecture selection, scaffolding, cross-cutting concerns, EF Core persistence, feature work, unit tests, integration tests, Aspire, and a modernization audit. Every prompt is structured the same way and carries explicit negative commands, because telling Claude what NOT to do is half the job.

I wrote the theory in my prompt engineering guide for Claude Code. This article is the practice: the actual prompts, refined across real .NET 10 projects, ready to paste into your terminal today.

Let’s get into it.

Why Do These Prompts Have Negative Commands?

A production-grade Claude Code prompt has five parts: context (what to read first), task (what to produce), constraints (versions and conventions), negative commands (what not to do), and verification (how Claude proves it worked). Miss any one of them and you get output that compiles but isn’t yours.

The negative commands matter most, and here’s the mechanism. Claude’s failure mode in .NET work is rarely ignorance. It’s initiative. Left unconstrained, it reaches for the statistically common path: Swashbuckle instead of Scalar, a repository layer over EF Core, AutoMapper for two-property mappings, try/catch blocks in every endpoint. None of that is wrong in general. It’s wrong for your codebase. A “Do NOT” line prunes the default path before Claude walks down it, which is far cheaper than reviewing and reverting it after.

Every prompt below ends with rules. Keep them when you adapt the prompts - they are the part doing the heavy lifting. Anthropic’s own Claude Code best practices make the same point: specific instructions with clear targets and constraints dramatically improve first-attempt success.

One nuance, because you’ll read advice claiming AI follows positive instructions better than prohibitions. Both camps are right, and the resolution is simple: a negative command works best when it carries its positive twin in the same breath. “Do NOT add Swashbuckle. Scalar only.” The ban blocks the default path; the replacement tells Claude where to go instead. A ban without a replacement invites improvisation. Every rule in this library is written as that pair, and you should keep the habit when you write your own.

One more thing before the library: anything in <angle brackets> is a placeholder. Fill it in. A prompt with an empty placeholder is a vague prompt with extra steps.

Stage 1: Brainstorming a Feature or Product

Every project I’ve rushed into code on day one, I’ve paid for by week three. This prompt forces the conversation to happen first, and it pairs naturally with Plan Mode, which blocks Claude from touching files while you think.

I want to build: <one-line description of the feature or app>.

Enter plan mode. Before proposing anything, ask me clarifying
questions about users, scale, existing systems, and constraints. Wait
for my answers. Then give me candidate approaches with honest
tradeoffs and the one you would actually pick.

Rules:
- Do NOT write code or create files in this session.
- Do NOT assume greenfield. Ask what already exists first.
- Do NOT pad the list with approaches you would never recommend.
- Do NOT agree with my framing by default. If a simpler version ships
  80% of the value, argue for it.

The last rule is the one I refuse to remove. An assistant that always agrees with you is a rubber stamp, not a collaborator.

Stage 2: Tech Research Without Stale Answers

Claude’s training data has a cutoff. NuGet does not. Any prompt that asks “what’s the best library for X” without forcing verification will get you confident answers about package versions that are 6 to 18 months old.

I need to pick a library for <problem, e.g. background jobs in an
ASP.NET Core API>.

Research the current options using web search, official docs, and
GitHub. For each candidate report: latest stable version, .NET 10
compatibility, license, release cadence over the last 12 months, and
open-issue health. Output a comparison table, then a one-paragraph
recommendation for my context: <team size, hosting, constraints>.

Rules:
- Do NOT quote version numbers or feature claims from memory. Your
  training data is stale by definition. Verify every fact.
- Do NOT list more than 4 candidates. Shortlist like a senior dev.
- Do NOT recommend a package with no release in the past year unless
  it is genuinely feature-complete, and say so if it is.
- If two options are effectively tied, say they are tied. Do NOT
  invent a winner.

Stage 3: Which Architecture Fits This App?

This is the prompt most developers never think to write, and it’s the one with the longest-lasting consequences. The trick is feeding Claude the inputs an architect would actually ask for, then banning the answer it would reach for by reflex.

Help me choose the architecture for a new .NET 10 application.

The app: <one-paragraph description>.
Team: <n> developers, <experience level>.
Deployment: <single server / containers / cloud PaaS>.
Domain: <CRUD-heavy / rich business rules / heavy integrations>.

Compare Vertical Slice Architecture, Clean Architecture, and a Modular
Monolith for THIS app specifically. Score each on: time to first
feature, onboarding cost, testability, and resilience to changing
requirements. End with one recommendation and the folder tree it
implies.

Rules:
- Do NOT evaluate microservices. Out of scope for this decision.
- Do NOT default to Clean Architecture because it is popular. Justify
  every layer you propose against my actual requirements.
- Do NOT propose abstractions for problems I have not described.
- Do NOT write code. Reasoning and structure only.
- If my requirements do not justify the ceremony, say "this is
  overkill" out loud. I want the honest answer, not the impressive one.

If you want the human version of this comparison first, I’ve written up Clean Architecture in .NET and when microservices actually make sense - useful for sanity-checking whatever Claude recommends.

Stage 4: Scaffolding the Baseline Solution

The approval gate in step 1 is the whole prompt. Reviewing a folder tree takes 30 seconds. Reviewing 40 generated files takes an hour, and by then you’ll accept things you shouldn’t.

Scaffold the baseline solution for <AppName> using the architecture we
agreed on: <vertical slice / clean architecture / modular monolith>.

Stack: .NET 10, ASP.NET Core Minimal APIs, EF Core 10, xUnit v3.
Solution format: .slnx. API reference UI: Scalar via AddOpenApi() and
MapScalarApiReference().

Steps:
1. Show me the full folder tree first. STOP and wait for my approval.
2. Create projects with the dotnet CLI, wire references, and enable
   Nullable + TreatWarningsAsErrors in Directory.Build.props.
3. Add exactly one health endpoint. Nothing else.
4. Run dotnet build and show me the output.

Rules:
- Do NOT add Swashbuckle or Swagger UI. Scalar only.
- Do NOT add MediatR, AutoMapper, or a repository layer. Patterns get
  decided per feature, not preinstalled.
- Do NOT create WeatherForecast or any demo entities.
- Do NOT install any package outside the stack above without asking.

Stage 5: Cross-Cutting Concerns in One Pass

Exception handling, logging, and validation touch every request, so I set them up once, immediately after scaffolding, with a prompt that names the exact primitives. Vague versions of this prompt (“add error handling”) are how you end up with try/catch wallpaper.

Set up cross-cutting concerns for this solution. Read the Program file
and folder structure first so everything lands where it belongs.

1. Global exception handling with IExceptionHandler, returning RFC 9457
   ProblemDetails responses.
2. Serilog structured logging: console sink in Development, JSON in
   Production, request logging middleware enabled.
3. FluentValidation wired into the endpoint pipeline, returning 400
   ProblemDetails with field-level errors.
4. When done, throw a test exception from the health endpoint, call it,
   show me the ProblemDetails JSON, then remove the test throw.

Rules:
- Do NOT put try/catch in endpoints or handlers. The exception handler
  owns errors.
- Do NOT swallow exceptions and return 200. Fail loudly.
- Do NOT log request bodies, tokens, or connection strings.
- Do NOT write custom middleware where ASP.NET Core ships a built-in.

Step 4 is my favorite pattern in this whole library: make Claude prove the wiring works, then clean up after itself. I use the same trick in nearly every setup prompt. The building blocks here each have a full article if you want to understand what Claude is wiring: global exception handling, Serilog structured logging, and FluentValidation.

Stage 6: Database Persistence with EF Core

EF Core is where unconstrained AI output hurts the most, because the mistakes are silent. EnsureCreated works great until you need your first migration. Missing AsNoTracking works great until you profile. This prompt bans the traps up front.

Add EF Core 10 persistence to this solution with PostgreSQL.

Read the existing entities and features first. Then:
1. Create the DbContext with one IEntityTypeConfiguration class per
   entity. No giant OnModelCreating.
2. Configure table names, max length on every string column, and
   indexes for the query patterns visible in the code.
3. Add the initial migration and show me the SQL via
   dotnet ef migrations script BEFORE anything touches a database.
4. Wire the connection string through configuration. No literals.

Rules:
- Do NOT use EnsureCreated. Migrations are the only schema path.
- Do NOT enable lazy loading proxies.
- Do NOT return IQueryable from any public method.
- Do NOT omit CancellationToken. Every async EF call accepts one.
- Read-only queries use AsNoTracking unless the handler mutates the
  entity.

The migration-script review in step 3 has caught more bad column types for me than any code review. Microsoft’s migration docs recommend the same script-first habit for production changes. If EF Core query behavior is fuzzy territory, my EF Core performance mistakes article covers why these specific negative commands exist.

Stage 7: Adding a Feature to an Existing Codebase

This is the prompt I run most, which also makes it the first one I converted to a skill (more on that below). The load-bearing line is “read the most recent feature folder first” - it turns your own codebase into the spec.

Add a new feature: <one-line description, e.g. "customers can cancel
an order that has not shipped yet">.

Before writing anything, read the most recent feature folder end to
end - endpoint, handler, validator, tests - and list the conventions
you see. Follow them exactly.

Then implement: request/response contracts, validation, the handler
with the real business rules, endpoint mapping, and DI registration.
Business rules to enforce: <rule 1>, <rule 2>.
Finish with tests that prove each rule.

Rules:
- Do NOT introduce a new pattern, package, or folder convention. Match
  what exists even where you disagree, and list objections at the end.
- Do NOT touch unrelated files. If a refactor is tempting, note it,
  don't do it.
- Do NOT leave business rules as TODO stubs. Implement them.
- Do NOT report done until dotnet build and dotnet test both pass.

For risky variants of this prompt - big refactors, framework upgrades - I run them in an isolated git worktree so a bad session never touches my main working copy.

Stage 8: Unit Tests That Earn Their Keep

Ask an AI for “unit tests” and you get coverage theater: 40 tests asserting that C# still works. The negative commands here exist to kill that entire category.

Write unit tests for <class or handler>. xUnit v3. Prefer real objects
and hand-rolled fakes; reach for a mocking library only when an
interface genuinely needs it.

Cover: the happy path, every business-rule rejection, and the edge
cases a reviewer would probe - empty collections, boundary values,
cancelled tokens. Name tests Method_Scenario_ExpectedOutcome.

Rules:
- Do NOT test the framework. No tests proving EF Core saves data or
  FluentValidation validates.
- Do NOT assert on log output or private state. Observable behavior
  only.
- Do NOT share mutable state between tests.
- Do NOT write one giant [Fact] with ten asserts. One behavior per
  test.
- If the class is hard to test, STOP and tell me. That is a design
  smell to fix, not a mocking puzzle to solve.

Stage 9: Integration Tests with a Real Database

The EF Core InMemory provider is not a test double for a relational database - it skips transactions, constraints, and SQL translation entirely. So the first negative command here is non-negotiable. Testcontainers gives you the real engine in a throwaway Docker container.

Set up integration tests for this API using WebApplicationFactory and
Testcontainers for PostgreSQL.

1. One shared collection fixture: starts the Postgres container, runs
   EF Core migrations, exposes a configured HttpClient.
2. Per-test isolation by resetting tables between tests. Do not spin
   up a container per test.
3. Write tests for <endpoint>: the success case, a validation failure
   asserting the ProblemDetails body, and an unauthorized request.
4. Run the suite and show me the summary.

Rules:
- Do NOT use the EF Core InMemory provider. Real database or nothing.
- Do NOT arrange test data through the API under test. Seed through
  the DbContext directly.
- Do NOT assert on status codes alone. Assert response bodies.
- Do NOT leave orphaned containers. The fixture owns the lifecycle.

Stage 10: Wiring Up Aspire

Aspire replaces the docker-compose file, the hardcoded connection strings, and the “works on my machine” onboarding doc in one move. The version-verification rule matters here more than anywhere: Aspire ships fast, and stale package versions are Claude’s most common Aspire mistake.

Add Aspire orchestration to this solution.

1. Create the AppHost and ServiceDefaults projects. Verify the latest
   stable Aspire package versions on NuGet first - do not trust memory.
2. Move PostgreSQL into the AppHost as a container resource and pass
   it to the API with WithReference. Delete the connection string from
   the appsettings file.
3. Wire ServiceDefaults into the API: OpenTelemetry, health checks,
   service discovery, resilience handlers.
4. Run the AppHost and confirm the dashboard shows a trace for one API
   request that hits the database. Show me evidence.

Rules:
- Do NOT keep the old connection string as a fallback. One source of
  truth.
- Do NOT add Docker Compose or Kubernetes manifests. Aspire owns local
  orchestration.
- Do NOT skip the dashboard verification. "It builds" is not "it
  works".

New to Aspire itself? The official Aspire docs cover the model, and I’ve written a full walkthrough below.

Stage 11: The Modernization Audit

I run this quarterly on long-lived projects, and always before adding a major feature to an older codebase. The report-only constraint is what makes it safe to run casually.

Audit this solution against current .NET best practices. Report only.
Change nothing.

Check: target frameworks, output of dotnet list package --outdated
(actually run it), deprecated or abandoned packages, obsolete API
usage, nullable annotation gaps, sync-over-async and missing
CancellationToken, and C# 14 features that would genuinely simplify
existing code.

Output a table: finding, file, risk, effort, recommendation. Then STOP
so I can pick what gets fixed.

Rules:
- Do NOT fix anything in this pass. Report only.
- Do NOT flag style preferences as findings. Working idiomatic code is
  not a defect.
- Do NOT recommend a major version bump without listing its breaking
  changes.
- Do NOT trust training data for "latest" versions. Verify against the
  CLI output and nuget.org.

The Rule That Ties It All Together: Repeated Prompt = Skill

Here’s the meta-lesson this library teaches once you use it for a few weeks: if you find yourself pasting the same prompt a third time, it has stopped being a prompt and started being a skill.

A skill is the same instructions moved into a SKILL.md file inside your repo, invoked with a slash command, version-controlled with your code. The prompt above for adding a feature? In my projects it became /feature <description>. The unit test prompt became /unit-tests <class>. The pasted version and the skill version contain the same words - the difference is that the skill never drifts, never gets a stale copy pasted from an old note, and improves in one place every time you refine it.

My conversion heuristic is simple. Prompts that run once per project stay in this library: brainstorming, architecture selection, scaffolding, Aspire setup. Prompts that run weekly become skills: feature work, unit tests, integration tests, the audit. Repetition is the signal, and three is my threshold.

This isn’t just my opinion anymore. The official Claude Code prompt library closes with the same instruction: once a prompt works for your project, make it repeatable by saving it as a skill so your whole team can run it as a slash command.

My Take: Where This Library Actually Pays Off

After months of running variations of these prompts on real .NET projects, my honest ranking: the feature prompt (Stage 7) delivers the most total value because it runs the most, but the architecture prompt (Stage 3) delivers the most value per run. One good architecture conversation before scaffolding beats ten refactoring sessions after.

The mistake I see most devs make with AI prompts is hoarding them somewhere dead: a note app, a wiki page, a pinned chat. Prompts are code. Put the one-shot ones in a prompts.md at your repo root, convert the repeated ones to skills, and let them evolve through pull requests like everything else.

And a caution: negative commands are guardrails, not guarantees. Claude occasionally steps over one, especially deep into a long session when the rule has scrolled far out of recent attention. The fix isn’t a longer prompt. It’s moving hard rules into your project memory file where they’re always loaded, keeping session prompts short, and reviewing diffs like you would a junior dev’s PR - because that’s the trust level any AI has earned so far.

Here’s the whole library on one screen:

Troubleshooting: When a Prompt Misbehaves

Claude installed a package you banned. Your rules were probably buried in a wall of text. Keep the rule list short (4-6 lines) and put it last in the prompt - and for absolute bans, back it up with a deny rule in your settings so the tool call itself gets blocked.

Claude ignored your codebase conventions. You told it what to build but not what to read. The “read the most recent feature folder first” line from Stage 7 is the fix: never assume Claude will explore on its own initiative.

The versions it used are outdated. Expected behavior, not a bug. Training data always trails NuGet. Any prompt touching package versions needs an explicit “verify, do not trust memory” command like Stages 2, 10, and 11 carry.

The output was too big to review. You skipped the approval gate. Add a “show me the plan and STOP” step before generation, the way Stage 4 gates on the folder tree. Cheap to review a plan, expensive to review 40 files.

A prompt works in one repo and fails in another. The prompt was compensating for missing project context. Move the stable rules (stack, conventions, banned packages) into that repo’s memory file, and keep the session prompt about the task only.

Key Takeaways

• Every reliable Claude Code prompt has five parts: context, task, constraints, negative commands, and verification.
• Negative commands are the hardest-working lines in a prompt because Claude’s failure mode is initiative, not ignorance - it adds popular things you didn’t ask for.
• Force verification steps: reviewed folder trees, migration SQL, passing test runs, dashboard traces. “It builds” is not “it works”.
• Never let AI quote package versions from memory. Every research, scaffold, and audit prompt needs an explicit verify command.
• The third time you paste a prompt, convert it to a skill. Once-per-project prompts stay in a library; weekly prompts become slash commands.

Frequently Asked Questions

Summary

You now have the full library: 11 structured prompts covering every stage of building a .NET application with Claude Code, from the first brainstorming conversation to the quarterly modernization audit. Paste them, fill the placeholders, keep the negative commands, and watch how much less time you spend reverting AI enthusiasm.

And remember the exit rule: the moment a prompt becomes routine, promote it to a skill. That’s how a prompt library stops being a document and becomes part of your codebase.

If you found this helpful, share it with your team - and if there’s a workflow stage you want a prompt for that I missed, drop a comment and let me know.

Happy Coding :)