debugging-and-error-recovery

Diagnose root causes of .NET test, build, and runtime failures with a structured triage checklist.

7|Updated Jan 11, 2026
One-click install
npx skills add https://github.com/peterblazejewicz/claude-plugins --skill debugging-and-error-recovery-peterblazejewicz
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: debugging-and-error-recovery
Source: https://github.com/peterblazejewicz/claude-plugins/tree/main/plugins/dotnet-skills/skills/debugging-and-error-recovery
Command: npx skills add https://github.com/peterblazejewicz/claude-plugins --skill debugging-and-error-recovery-peterblazejewicz

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? When a .NET test fails, a build breaks, or runtime behavior diverges from expectations, developers often guess at fixes or patch symptoms instead of root causes. This Skill enforces a stop-the-line, evidence-preserving debugging process that systematically reproduces, localizes, reduces, and fixes failures in C#/.NET projects. ## Core Features & Use Cases - Six-step triage workflow: Reproduce, Localize, Reduce, Fix Root Cause, Guard Against Recurrence, and Verify End-to-End, with concrete dotnet test --filter, git bisect, and dotnet build -warnaserror commands. - Error-specific triage trees: Decision flows for test failures, build failures (CS/nullable errors, analyzer diagnostics, NuGet restore, global.json SDK mismatches), and runtime errors (NullReferenceException, DbContext concurrency, missing DI registrations, TaskCanceledException, Avalonia/MAUI binding issues). - Regression guarding and safe fallbacks: xUnit regression-test patterns, graceful-degradation C# examples that never swallow OperationCanceledException, and instrumentation guidance using ILogger, OpenTelemetry, and EF Core LogTo. - Use Case: After dotnet test fails on a search feature, follow the checklist to reproduce the failure in isolation, bisect the offending commit, fix the EF Core cartesian-duplication query with AsSplitQuery, and add a regression test that fails without the fix. ## Quick Start Ask the AI to systematically debug a failing dotnet test or broken build by following the root-cause triage checklist instead of guessing at fixes.

Frequently Asked Questions about debugging-and-error-recovery

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I debug a failing dotnet test systematically?

Run the failing test in isolation with dotnet test --filter and detailed verbosity, then follow a triage order: reproduce reliably, localize the failing layer, reduce to a minimal case, fix the root cause, and add a regression test. Disable test parallelization to rule out concurrency flakes.

How to find which commit introduced a bug in .NET?

Use git bisect with an automated test command: mark the current commit bad and a known-good commit good, then run git bisect run dotnet test --filter with the failing test name. Git checks out midpoint commits until it identifies the exact change that broke the test.

Why does EF Core throw 'A second operation was started on this context'?

This InvalidOperationException means a DbContext instance is being used concurrently, which EF Core does not support. The usual fix is correcting dependency injection scoping so DbContext is registered as Scoped rather than Singleton, ensuring each operation gets its own context instance.

Does this debugging approach work with both xUnit and MSTest?

Yes, the triage commands cover both frameworks. Parallel execution can be disabled with xUnit.ParallelizeTestCollections=false for xUnit or MSTest.Parallelize.Workers=1 for MSTest, and fixture scoping guidance addresses IClassFixture and ICollectionFixture state leakage.

When should I skip a failing test instead of fixing it?

Never skip a failing test with Fact(Skip) just to continue feature work. If the test is outdated, update it; if the code is wrong, fix the code. Flaky tests should be investigated for timing issues, fixture order dependence, or shared static state rather than ignored.

Why is catching OperationCanceledException treated as a red flag?

OperationCanceledException signals intentional cancellation via a CancellationToken, not a fault. Swallowing it in a generic catch block breaks cooperative cancellation and hides timeouts or user cancellations, so exception filters like 'when (ex is not OperationCanceledException)' should exclude it from error handling.