Claude/ChatGPT Prompt to Find and Fix C# Async/Await Pitfalls

What this prompt does

This prompt makes the model a senior C# engineer reviewing async code for deadlock and throughput bugs, returning working before/after diffs rather than descriptions. You paste your [code], set the [app_type], and name a [runtime_concern], and it hunts for sync-over-async, missing ConfigureAwait, async void misuse, unnecessary Task.Run, and captured scoped services in background tasks — fixing each with a before/after pair and a one-line explanation of the failure mode.

The structure works because async bugs are nearly invisible in a code read but lethal under concurrency, so the prompt insists on paste-ready fixed code instead of a lecture. The classic culprit — a .Result or .Wait() deep in a service causing thread-pool starvation — gets surfaced first. [runtime_concern] (for example, thread starvation under load) tells the model which failure mode to prioritise, and [app_type] decides whether ConfigureAwait advice even applies, since it matters in library code but not in ASP.NET Core request handlers. Pairing each fix with a one-line explanation of the failure mode is what makes the review teachable: the team learns why the change matters, so the same mistake is less likely to reappear in the next pull request.

When to use it

• An app stalls or deadlocks under load and you suspect sync-over-async.
• You're seeing thread-pool starvation and want every .Result and .Wait() flagged.
• You want async void outside event handlers found and converted to Task-returning.
• You suspect unnecessary Task.Run in request handlers burning threadpool.
• You're worried about captured HttpContext or scoped services in background tasks.
• You want paste-ready fixes your team can apply, not a write-up to re-read.

Example output

Expect a numbered list where each item is a before/after pair: the offending code, the corrected version, and a one-line explanation of the failure mode it fixes. Items cover sync-over-async, ConfigureAwait gaps, async void, needless Task.Run, and captured scoped services. The diffs are concrete enough to apply directly rather than paraphrased advice.

Pro tips

• Paste real [code] into the prompt — the more actual code you give it, the more grounded the diffs.
• Set [runtime_concern] to your real symptom so the model prioritises the matching failure mode.
• Use [app_type] accurately; ConfigureAwait(false) advice is relevant in libraries but largely moot in ASP.NET Core endpoints.
• Reproduce the deadlock under concurrency first, then confirm the suggested fix actually clears it — a fix that compiles isn't proof.
• Watch for the async void cases; outside event handlers they swallow exceptions and are easy to miss.
• Apply one category of fix at a time so you can attribute any behaviour change to the right change.
• Check the background-task findings carefully; a captured HttpContext or scoped service can throw only intermittently, which makes it brutal to diagnose later.
• Don't blindly sprinkle Task.Run to "make things async" — the prompt flags exactly the cases where it just burns threadpool for no gain.