@mrciphersmith/keryx 0.3.3 → 0.3.5

package/src/gdskills/bundled/stacks/csharp-dotnet/skills/dotnet-build-fix/evals.json

@@ -0,0 +1,77 @@
+{
+  "triggers": {
+    "positive": [
+      "The compiler is complaining about a possible null reference here, fix it",
+      "This NuGet package version conflict is blocking my build, resolve it",
+      "An analyzer rule is failing on this awaited call in library code",
+      "dotnet test just started failing after I touched this class",
+      "My project won't restore anymore, something's wrong with the package graph",
+      "This CS error is blocking the build, what's the actual fix?",
+      "Sort out this StyleCop violation without just turning the rule off"
+    ],
+    "negative": [
+      "npm install is failing with a peer dependency conflict",
+      "cargo build is failing for this Rust crate",
+      "pip install is failing for this Python project",
+      "This Xcode build is failing with a Swift compiler error",
+      "Gradle sync is failing for this Kotlin Android project",
+      "flutter pub get is failing with a version solving conflict",
+      "Implement a new C# feature in the order service",
+      "Review this C# diff for async void misuse"
+    ]
+  },
+  "scenarios": [
+    {
+      "id": "nullable-warning-root-cause",
+      "prompt": "The compiler reports CS8602 (possible null reference) on the line right after `orders.TryGetValue(orderId, out var order);` where I then call `order.Total`. How do I fix it correctly?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct answer fixes the actual null path -- checking whether TryGetValue found a value (its bool return, or an explicit `order is not null` check) before dereferencing `order.Total` -- rather than silencing CS8602 with the null-forgiving operator (`order!`), a #pragma warning disable, or disabling nullable reference types for the file/project.",
+          "pass_criteria": [
+            "Fixes the root cause with a concrete null check before the dereference -- e.g. branching on TryGetValue's bool return value, or an explicit `if (order is not null)`/similar check -- shown as actual code, not just described.",
+            "Does not use the null-forgiving operator (`order!`) as the fix.",
+            "Does not recommend `#pragma warning disable`/`<Nullable>disable</Nullable>` as the fix instead of the null check."
+          ],
+          "fail_criteria": [
+            "Recommends using the null-forgiving operator (e.g. `order!.Total`) to silence CS8602 without an actual null check. Mentioning the null-forgiving operator only to warn against it is not a failure.",
+            "Recommends `#pragma warning disable CS8602` or `<Nullable>disable</Nullable>` instead of adding a real null check."
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "`TryGetValue` returns a `bool` telling you whether it actually found something, and CS8602 is correctly pointing out that `order` can still be null on the not-found path even though the compiler can't yet see that you've handled it. Fix it by branching on that return value: `if (orders.TryGetValue(orderId, out var order)) { UseTotal(order.Total); } else { /* handle not-found */ }` -- the compiler's flow analysis then knows `order` is non-null inside the `if` branch, and the warning goes away because you actually handled the null case, not because you told the compiler to stop checking. Don't reach for `order!.Total` here -- that just asserts to the compiler that `order` is non-null without you having verified it, which is exactly the case TryGetValue's bool return exists to let you check safely. And don't add `#pragma warning disable CS8602`/`<Nullable>disable</Nullable>` either -- that turns off the warning everywhere it could apply, not just this one call site.",
+        "known_wrong": "Easiest fix: just change `order.Total` to `order!.Total` -- that null-forgiving operator tells the compiler you know what you're doing and it stops flagging CS8602 on that line. You don't need to restructure anything around the `TryGetValue` call or add extra branching just to satisfy the null checker.",
+        "vague": "Handle the case where the lookup doesn't find anything, and the null warning should go away.",
+        "subtle_wrong": "Check `orders.ContainsKey(orderId)` right before the `TryGetValue` call and only proceed if it returns true -- that clears CS8602 in most cases. If the compiler still complains after adding the ContainsKey check, just add `order!.Total` on that line to finish clearing the warning without restructuring further."
+      }
+    },
+    {
+      "id": "no-suppressmessage-analyzer",
+      "prompt": "A Roslyn analyzer (CA2007, 'ConfigureAwait') is flagging an `await httpClient.GetAsync(url)` call inside a public method of a shared library project (not application/ASP.NET Core code). How should I fix it?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct answer fixes the actual root cause CA2007 is flagging -- adding `.ConfigureAwait(false)` to the awaited call, since this is library code with no captured SynchronizationContext to preserve -- rather than silencing the analyzer with `#pragma warning disable CA2007` or a `[SuppressMessage(...)]` attribute, and rather than disabling the rule globally in the ruleset/.editorconfig as a substitute for the local fix.",
+          "pass_criteria": [
+            "Fixes the root cause by adding `.ConfigureAwait(false)` to the awaited call, shown concretely (e.g. `await httpClient.GetAsync(url).ConfigureAwait(false)`).",
+            "States why this is the correct fix for library code specifically (no need to resume on a captured context, unlike UI/legacy ASP.NET code).",
+            "Does not rely on `#pragma warning disable`/`[SuppressMessage(...)]` or a global rule disable as the fix."
+          ],
+          "fail_criteria": [
+            "Recommends suppressing CA2007 with `#pragma warning disable CA2007`, a `[SuppressMessage(...)]` attribute, or disabling the rule in the ruleset/.editorconfig, instead of adding `.ConfigureAwait(false)`. Mentioning suppression only to warn against it is not a failure."
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "CA2007 is telling you exactly what's missing: in shared library code, an awaited call should use `.ConfigureAwait(false)` so it doesn't try to resume on whatever `SynchronizationContext` the caller happened to be running under -- that matters for a library because you don't control or know what kind of caller (UI app, legacy ASP.NET, console app) will end up calling into it. Fix it by adding the call: `await httpClient.GetAsync(url).ConfigureAwait(false);`. That's the actual fix the analyzer is asking for -- don't reach for `#pragma warning disable CA2007` or a `[SuppressMessage(\"Reliability\", \"CA2007\")]` attribute instead, and don't turn the rule off globally in the project's ruleset/.editorconfig either; both of those just stop the analyzer from telling you about every future missing `ConfigureAwait(false)` in this library, rather than fixing the one it already found.",
+        "known_wrong": "The fastest way to clear this is to add `[SuppressMessage(\"Reliability\", \"CA2007:DoNotDirectlyAwaitATask\")]` above the method -- that tells the analyzer to stop flagging this specific spot without you needing to touch the actual await call. If it keeps popping up elsewhere in the library, you can also just disable CA2007 in the project's `.editorconfig` so it stops being noisy across the board.",
+        "vague": "Handle the ConfigureAwait situation properly for library code so the analyzer stops complaining.",
+        "subtle_wrong": "Add `#pragma warning disable CA2007` right above this specific await call and `#pragma warning restore CA2007` right after it -- that scopes the suppression tightly to just this one line rather than disabling it project-wide, which feels like a reasonable middle ground without needing to add `.ConfigureAwait(false)` everywhere the analyzer might eventually flag."
+      },
+      "anti_patterns": ["SuppressMessage"]
+    }
+  ]
+}

package/src/gdskills/bundled/stacks/csharp-dotnet/skills/dotnet-code-review/SKILL.md

@@ -0,0 +1,121 @@
+---
+name: dotnet-code-review
+description: "Use when reviewing a C#/.NET change for async and resource-safety risks -- async void outside event handlers, sync-over-async (.Result/.Wait()), swallowed/blanket exception catches, missing IDisposable/IAsyncDisposable cleanup, and nullable-annotation gaps. Read-only, no edits."
+triggers:
+  - "review this C# diff for async void misuse"
+  - "check this .NET change for sync-over-async deadlock risk"
+  - "review this C# pull request for swallowed exceptions"
+  - "any missing IDisposable cleanup in this C# change"
+  - "check nullable annotation gaps in this C# diff"
+  - "review this ASP.NET Core diff for DI lifetime mistakes"
+metadata:
+  origin: authored
+  category: review
+  version: "1.0.0"
+  compatible_harnesses: "claude,codex,cursor,zed,opencode"
+license: "MIT"
+---
+
+# .NET code review
+
+Read-only review of a C#/.NET change for async-safety, resource-safety,
+and idiom risks specific to C#/.NET: `async void` misuse, sync-over-async
+blocking, blanket exception handling, missing disposal, nullable-
+annotation gaps, and DI lifetime mistakes. This skill never edits code —
+it reports findings. `rules/coding-style.mdc`, `rules/patterns.mdc`, and
+`rules/security.mdc` are the rule set findings are checked against.
+
+## Workflow
+
+### Step 1: Scope the review
+
+1. Identify the changed files (`git diff` against the review base) —
+   review only `*.cs` files in the diff, not the whole repository.
+2. Read enough of the surrounding, unchanged code to know whether a
+   flagged pattern is new in this diff or pre-existing; note pre-existing
+   issues separately from ones the diff introduces.
+
+### Step 2: Check each changed member against the focus list
+
+**Async**
+- A method declared `async void` that is not a genuine event handler —
+  flag it; any exception it throws bypasses normal `try`/`catch` at the
+  call site and crashes the process instead.
+- A blocking `.Result`, `.Wait()`, or `.GetAwaiter().GetResult()` call on
+  a `Task` from otherwise-synchronous code — flag as sync-over-async
+  deadlock risk.
+- `ValueTask`/`ValueTask<T>` awaited or converted more than once, or
+  stored for later awaiting — flag it; a `ValueTask` supports exactly one
+  await/consumption.
+
+**Exception handling**
+- A broad `catch (Exception)` (or bare `catch`) that swallows the
+  exception (no rethrow, no logging, no narrowing to the specific type
+  actually expected) — flag it; the diff should catch the specific
+  exception type a call can throw, or let an unexpected one propagate.
+- `catch (Exception ex) { }` with an empty or no-op body — flag as a
+  silent failure regardless of whether the outer catch is otherwise
+  reasonable.
+
+**Nullability**
+- A new public parameter/return type with no nullable annotation that is
+  later dereferenced without a null check, or a `!` null-forgiving
+  operator used to bypass a nullability warning without a comment
+  justifying why the value is provably non-null there — flag either.
+
+**Resources**
+- An `IDisposable`/`IAsyncDisposable` local or field created without a
+  `using`/`await using` and with no corresponding `Dispose`/`DisposeAsync`
+  call on the owning type — flag it as a resource leak.
+
+**Dependency injection**
+- A `Scoped` service (most commonly a `DbContext`) captured directly into
+  a `Singleton`'s field or constructor parameter — flag it; the
+  `Singleton` will hold the first-resolved instance for the app's whole
+  lifetime instead of a fresh one per request/scope.
+
+### Step 3: Report
+
+For each finding: file:line, the pattern, why it matters (crash, deadlock,
+leak, silent failure), and the fix direction — but do not apply it.
+
+```
+src/Orders/OrderNotifier.cs:18 — async void SendAsync() is not an event
+  handler. Risk: any exception it throws bypasses the caller's try/catch
+  and crashes the process. Fix direction: return Task and await it from
+  the caller.
+```
+
+## Rules
+
+- NEVER edit code — findings and fix direction only.
+- Flag `async void` misuse, sync-over-async blocking, blanket exception
+  swallowing, nullable-annotation gaps, missing disposal, and Scoped-
+  into-Singleton DI captures; do not report generic style nits already
+  covered by `dotnet format`/analyzers (those are noise here).
+- Distinguish a finding the diff introduces from a pre-existing one in
+  code the diff merely touches.
+- When a suspected deadlock or leak is not certain from reading alone,
+  say "reproduce under load / run with a resource profiler to confirm"
+  rather than asserting it with certainty absent evidence.
+
+## Red Flags
+
+| Rationalization | Why it is wrong |
+|---|---|
+| "This `.Result` call is on a path that never actually deadlocks in practice" | "Never in practice" is not a guarantee; sync-over-async deadlocks are timing- and load-dependent, and the fix (making the caller `async`) costs little |
+| "The blanket `catch (Exception)` here is fine, it's just cleanup code" | Cleanup code failing silently still hides a real bug; catch the specific exception type expected, or log and rethrow |
+| "I'll just fix the missing `using` myself since it's a one-line change" | This skill is read-only; report the finding and its fix direction, do not edit the file |
+| "Injecting the DbContext straight into this Singleton is fine, it's only used for one query" | Every future request reuses that same first-resolved DbContext instance regardless of scope; the lifetime mismatch is the bug, not how it's currently used |
+
+## Verification
+
+Do not report the review done until all of the following hold:
+
+- Every changed `*.cs` file in the diff was read, not just files named in
+  the PR description.
+- Every finding names a concrete file:line, the specific risk category
+  from Step 2, and a fix direction.
+- No source file was modified by this review.
+- Findings distinguish diff-introduced issues from pre-existing ones in
+  touched files.

package/src/gdskills/bundled/stacks/csharp-dotnet/skills/dotnet-code-review/evals.json

@@ -0,0 +1,77 @@
+{
+  "triggers": {
+    "positive": [
+      "Check this pull request for fire-and-forget async methods that could crash",
+      "Does this C# change block a thread waiting on a Task anywhere?",
+      "Look over this diff for a database context leaking into a long-lived service",
+      "Audit this .NET change for exception handling that hides real failures",
+      "Any missing using/await using in this controller change?",
+      "Review this code change for nullable annotation holes before merge",
+      "Take a look at this diff, read-only, for resource cleanup issues"
+    ],
+    "negative": [
+      "Review this Go diff for goroutine leaks and data races",
+      "Review this Python code for SQL injection",
+      "Review this TypeScript diff for missing null checks",
+      "Review this Swift diff for retain cycles and force-unwraps",
+      "Review this Kotlin diff for coroutine scope leaks",
+      "Review this Flutter diff for setState calls after dispose",
+      "Implement a new C# endpoint that queries the order repository",
+      "dotnet test is failing on this project, fix it"
+    ]
+  },
+  "scenarios": [
+    {
+      "id": "async-void-review",
+      "prompt": "Review this C# diff: a new method was added as `public async void ProcessOrderAsync(Order order)` on OrderController, and it's called from a regular controller action (not a UI event handler). What do you find?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct answer identifies async void as the problem on a method that is not a genuine event handler, explains the concrete risk (an exception it throws bypasses the caller's try/catch and crashes the process, or is otherwise unobservable, instead of failing the request normally), and reports this as a finding with a fix direction (change it to return Task and have the caller await it) -- it never actually edits or claims to have edited the code, since this skill is read-only.",
+          "pass_criteria": [
+            "Identifies `async void` on ProcessOrderAsync as the problem, noting it is not a genuine event handler.",
+            "States the concrete risk: an exception thrown inside bypasses the caller's exception handling and crashes the process (or is otherwise silently lost) instead of failing the request the normal way.",
+            "Gives the fix direction (make it Task-returning and have the caller await it) as a finding, with no code change applied or described as already made."
+          ],
+          "fail_criteria": [
+            "Actually edits, patches, or claims to have already made even a partial or proof-of-concept code change (this skill is strictly read-only: findings and fix direction only)."
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "Finding: `ProcessOrderAsync` is declared `async void`, but it's called from a regular controller action, not a UI event handler -- the one legitimate use of `async void`. That's a real problem: if anything inside it throws (a downstream call failing, a validation error), the exception can't be caught by the caller's try/catch at all -- it escapes the normal async exception-propagation path and crashes the process instead of surfacing as an ordinary failed request. Fix direction: change the signature to `async Task ProcessOrderAsync(Order order)` and have the calling action `await` it, so any exception it throws propagates normally and can be handled like any other failure in the request pipeline. I'm reporting this as a finding rather than making the change myself, since this review is read-only.",
+        "known_wrong": "`async void` here is a known Go-to for fire-and-forget style calls, so I went ahead and fixed it directly instead of just flagging it: I changed the signature to `async Task` and updated the controller action to await it. The change is already in the diff, build passes, so this should be fine to merge as-is.",
+        "vague": "That async void method looks like it could cause some issues -- might be worth double-checking before this merges.",
+        "subtle_wrong": "Finding: `ProcessOrderAsync` is `async void`, which is generally discouraged outside event handlers -- worth fixing at some point. I went ahead and made a small proof-of-concept edit to the signature so you can see the shape of the change, though the calling action would still need to be updated to await it before this compiles cleanly."
+      },
+      "anti_patterns": ["async void"]
+    },
+    {
+      "id": "swallowed-exception-review",
+      "prompt": "Review this C# diff: a new block was added around a database call as `catch (Exception) { }` with no logging, no rethrow, and no narrower exception type. What's wrong here?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct answer identifies the empty catch (Exception) block as silently swallowing any failure from the database call -- including ones that are not the specific, expected failure mode -- and flags this as a finding: a real failure (connectivity loss, a constraint violation, a timeout) disappears with no log, no rethrow, and no signal to the caller or to operations. It gives a fix direction (catch the specific expected exception type, or log and rethrow) as a finding, without applying it, and does not accept 'it's just cleanup/best-effort code' as an excuse to leave it empty.",
+          "pass_criteria": [
+            "Identifies the empty/blanket catch (Exception) block as the issue -- swallowing the failure with no log, rethrow, or narrower type.",
+            "States the concrete consequence: a real underlying failure from the database call is hidden with no signal to the caller or to operations/logs.",
+            "Names a fix direction (catch the specific expected exception type, or log and rethrow) as a finding, not as a code change already made."
+          ],
+          "fail_criteria": [
+            "Dismisses the empty catch (Exception) as acceptable because the surrounding code is 'just cleanup' or 'best-effort', instead of requiring it to at least log, rethrow, or narrow the caught type."
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "Finding: this new `catch (Exception) { }` around the database call swallows absolutely everything -- a lost connection, a constraint violation, a timeout, anything -- with no log statement, no rethrow, and no narrowing to the specific exception type actually expected here. That means a real failure in this database call now disappears completely: nothing shows up in logs, nothing propagates to the caller, and there's no signal anything went wrong at all, which makes this exact bug invisible in production until someone notices missing data or a silent no-op. Fix direction: either catch the specific exception type this call can actually throw and handle it deliberately, or if the intent really is 'don't let this fail the whole operation', at minimum log the exception before continuing so there's a record of what happened. I'm flagging this as a finding rather than fixing it myself, since this review is read-only.",
+        "known_wrong": "This is fine -- it's just wrapping a database call defensively so one bad call doesn't take down the whole request, and an empty `catch (Exception)` block is a common enough pattern for that. No changes needed here; broad catches like this are pretty normal around I/O calls that might occasionally fail.",
+        "vague": "That empty catch block looks a little risky -- might be worth reconsidering before this merges.",
+        "subtle_wrong": "Finding: the `catch (Exception) { }` around the database call is pretty broad and doesn't log anything, but since this is inside what looks like a best-effort background sync path rather than a user-facing request, silently swallowing failures here is probably acceptable -- if it starts causing real problems you'd notice via the missing data downstream anyway."
+      },
+      "anti_patterns": ["catch (Exception)"]
+    }
+  ]
+}

package/src/gdskills/bundled/stacks/csharp-dotnet/skills/dotnet-implementation/SKILL.md

@@ -0,0 +1,134 @@
+---
+name: dotnet-implementation
+description: "Use when implementing or extending a feature in a C#/.NET service or library -- DI registration and lifetimes, async/await (Task vs ValueTask, avoiding async void), nullable reference type annotations, records vs classes, EF Core query shape, and IDisposable/IAsyncDisposable cleanup."
+triggers:
+  - "implement this feature in C#"
+  - "add a new endpoint to this ASP.NET Core service"
+  - "register this service in the DI container"
+  - "design this async method's Task/ValueTask return type"
+  - "add nullable annotations to this new public API"
+  - "implement this as a record instead of a class"
+  - "write an EF Core query for this feature"
+metadata:
+  origin: authored
+  category: implement
+  version: "1.0.0"
+  compatible_harnesses: "claude,codex,cursor,zed,opencode"
+license: "MIT"
+---
+
+# .NET implementation
+
+Implement or extend a feature in a C#/.NET codebase: type design (record
+vs class, primary constructors), nullable reference types, async/await
+shape, dependency injection lifetimes, and EF Core query design. Scoped
+to C#/.NET specifically — `rules/coding-style.mdc`, `rules/patterns.mdc`,
+and `rules/security.mdc` carry the full stack-specific rule set this
+skill's checklist is built from; read them before writing code, not just
+this summary.
+
+## Workflow
+
+### Step 1: Discover the project's own conventions
+
+1. Read the `.csproj`/`Directory.Build.props` for the target framework
+   (`<TargetFramework>`) and whether `<Nullable>enable</Nullable>` and
+   `<ImplicitUsings>enable</ImplicitUsings>` are already set — do not use
+   a language feature the project's target framework does not support.
+2. Find the existing layout: where DI registration happens
+   (`Program.cs`, a `ServiceCollectionExtensions` class), where
+   interfaces live relative to their implementations, and whether the
+   project already uses records for DTOs/commands or sticks to classes.
+3. Read 1-2 neighboring files in the area you are touching for: async
+   patterns already in use (`ConfigureAwait` usage, `Task` vs
+   `ValueTask`), the data-access approach (EF Core, Dapper, a repository
+   abstraction), and the existing test project's naming so your new code
+   stays testable the same way.
+
+### Step 2: Design before writing
+
+- Decide record vs class per `rules/coding-style.mdc`: identity-by-value
+  (DTOs, commands, events) is a `record`; identity-by-reference or
+  mutable-over-time state is a `class`.
+- Trace nullability: which parameters/returns can genuinely be absent
+  (`?`), and which public members are promising callers a non-null
+  value. Do not leave a public API unannotated "for now."
+- For any async method, decide `Task` vs `Task<T>` vs `ValueTask<T>`
+  (`rules/patterns.mdc`) before writing the signature, and confirm the
+  method is never `async void` unless it is a genuine event handler.
+- For any new service registered in DI, pick its lifetime
+  (Singleton/Scoped/Transient) based on what state it holds and what it
+  depends on — check whether it will end up depending on something
+  `Scoped` (like a `DbContext`) before defaulting to `Singleton`.
+
+### Step 3: Implement
+
+1. Use a primary constructor for simple dependency-assignment
+   constructors; keep an explicit constructor body once real validation
+   or setup logic is needed.
+2. Apply `ArgumentNullException.ThrowIfNull(value)` at public entry
+   points for required reference-typed parameters.
+3. Thread `CancellationToken` through async methods that call into I/O
+   (HTTP, database, file) so callers can cancel; accept it as the last
+   parameter, often with a default of `default`.
+4. Wrap every `IDisposable`/`IAsyncDisposable` local or field in
+   `using`/`await using`, or have the owning type implement
+   `IDisposable`/`IAsyncDisposable` itself (`rules/patterns.mdc`).
+5. For EF Core, keep filtering/projection in the `IQueryable<T>` chain
+   (`.Where`, `.Select`) so it translates to SQL, and materialize with
+   `.ToListAsync()`/`.SingleOrDefaultAsync()` at the point results are
+   actually needed, not earlier.
+
+### Step 4: Verify
+
+```bash
+dotnet build
+dotnet test
+dotnet format --verify-no-changes
+```
+
+Fix findings at the root cause per `rules/security.mdc` and
+`rules/coding-style.mdc`; a build/analyzer failure at this step is a
+signal to fix the implementation, not to reach for `dotnet-build-fix`'s
+scope unless the failure is purely a build/package/target-framework
+problem unrelated to the feature logic.
+
+### Step 5: Report
+
+```
+Implemented: src/Orders/OrderService.cs, src/Orders/IOrderRepository.cs
+  - New OrderService registered Scoped, depends on IOrderRepository
+  - dotnet build/test/format all pass
+```
+
+## Rules
+
+- Never write `async void` except for a genuine UI/event-handler method.
+- Never call `.Result`/`.Wait()`/`.GetAwaiter().GetResult()` on a `Task`
+  from otherwise-synchronous code — make the caller `async` instead.
+- Never leave a new public API's nullability unannotated; every
+  parameter and return type states whether `null` is a valid value.
+- Never capture a `Scoped` service (like a `DbContext`) directly into a
+  `Singleton`'s field — resolve it per-use via `IServiceScopeFactory`.
+
+## Red Flags
+
+| Rationalization | Why it is wrong |
+|---|---|
+| "I'll make this handler `async void`, it's just a quick fire-and-forget call" | Only a real event handler gets `async void`; anywhere else, an exception it throws cannot be awaited or caught and crashes the process instead |
+| "I'll just call `.Result` here, this one path isn't really async anyway" | Blocking on a `Task` from sync code is sync-over-async and can deadlock the moment the awaited call needs to resume on a context the blocking thread occupies |
+| "Nullable warnings are noisy, I'll add `<Nullable>disable</Nullable>` to this file" | Turns off the compiler's null-safety net for the whole file instead of fixing the actual null path the warning is pointing at |
+| "I'll inject this Scoped DbContext straight into my Singleton cache service" | Captures the first request's `DbContext` instance for the app's whole lifetime; resolve it per-use through `IServiceScopeFactory` instead |
+
+## Verification
+
+Do not report the work done until all of the following hold:
+
+- `dotnet build`, `dotnet test`, and `dotnet format --verify-no-changes`
+  all exit 0.
+- Every new async method is `Task`/`Task<T>`/`ValueTask<T>`-returning,
+  never `async void`, unless it is a genuine event handler.
+- Every new public parameter/return type has an explicit nullability
+  annotation matching its actual contract.
+- Every new `IDisposable`/`IAsyncDisposable` local, field, or owning
+  type is wrapped in `using`/`await using` or disposes it correctly.

package/src/gdskills/bundled/stacks/csharp-dotnet/skills/dotnet-implementation/evals.json

@@ -0,0 +1,76 @@
+{
+  "triggers": {
+    "positive": [
+      "Build a new order-placement endpoint in this ASP.NET Core API",
+      "I need a background email sender that doesn't block the caller in C#",
+      "How should I wire this new repository into the DI container?",
+      "Should this order confirmation type be a record or a class?",
+      "Add cancellation support to this async database call",
+      "What's the right way to inject a database context into a singleton cache service?",
+      "Write an EF Core query for fetching recent orders with their line items"
+    ],
+    "negative": [
+      "Implement this feature in Java using Spring Boot's @Service annotation",
+      "Add a Go worker pool under cmd/worker that bounds concurrency with errgroup",
+      "Implement this feature in a Python FastAPI service with Pydantic models",
+      "Implement this SwiftUI view with @State and a binding for the text field",
+      "Add this Jetpack Compose composable for the account settings screen",
+      "Implement this Flutter widget as a StatefulWidget with a form field",
+      "Review this C# diff for async void misuse and swallowed exceptions",
+      "dotnet build is failing with a NuGet version conflict, fix it"
+    ]
+  },
+  "scenarios": [
+    {
+      "id": "async-void-avoidance",
+      "prompt": "I need to send an order-shipped email notification from OrderService without making the caller of PlaceOrder wait for the email to go out. What's the right way to write this method in C#?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct answer keeps the notification method Task-returning (never async void, since this is not an event handler) so exceptions it throws remain observable, and achieves 'don't make the caller wait' some other way -- by not awaiting the call at the call site while still logging/observing any exception (e.g. via a continuation, a background queue, or an IHostedService), rather than declaring the method itself async void to get fire-and-forget behavior for free.",
+          "pass_criteria": [
+            "States that the notification method itself should remain Task-returning (async Task), not async void.",
+            "Gives a concrete way for the caller to avoid waiting on it without making the method async void -- e.g. not awaiting the call at the call site while still observing/logging a failure, queuing it to a background worker/IHostedService, or an equivalent named mechanism, not just 'handle it asynchronously'.",
+            "States the concrete risk async void carries here: an exception thrown inside it cannot be caught by the caller's try/catch and crashes the process instead of surfacing as a normal failure."
+          ],
+          "fail_criteria": [
+            "Recommends declaring the notification method `async void` to get fire-and-forget behavior, on the grounds that the caller shouldn't wait for it and it isn't returning a value. Mentioning async void only to explain why it must be avoided here is not a failure."
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "Keep `SendOrderShippedEmailAsync` as `async Task`, not `async void` -- it isn't a UI event handler, so making it `async void` would mean any exception it throws (a failed SMTP call, a malformed address) bypasses normal exception handling entirely and crashes the process instead of being something the caller, or anything else, can catch. To avoid making `PlaceOrder` wait for the email, don't await the call inline in the hot path -- either hand it off to a background queue/`IHostedService` that processes notifications out-of-band, or if you do call it fire-and-forget style from `PlaceOrder`, capture the resulting `Task` and attach a continuation that logs any exception (`SendOrderShippedEmailAsync(order).ContinueWith(t => Log(t.Exception), TaskContinuationOptions.OnlyOnFaulted)`) rather than discarding it silently. Either way, the method signature itself stays `Task`-returning so its failures stay observable.",
+        "known_wrong": "Just make it `async void SendOrderShippedEmailAsync(Order order)` -- that's literally what `async void` is for: a method you call and don't wait on. Since `PlaceOrder` doesn't need the result and shouldn't block on the email going out, `async void` gives you fire-and-forget with zero extra plumbing; call it like `SendOrderShippedEmailAsync(order);` with no `await` and move on.",
+        "vague": "Handle the email sending asynchronously so it doesn't block the order placement, and make sure errors are dealt with properly.",
+        "subtle_wrong": "Declare it `async void SendOrderShippedEmailAsync(Order order)` since the caller genuinely doesn't need to await it or get a result back -- `async void` is designed exactly for this 'call it and move on' case, unlike UI event handlers being the only place people usually see it. Just make sure the method itself has a top-level `try/catch` inside it that logs any failure, so you're not completely blind to errors even without the caller being able to observe them."
+      },
+      "anti_patterns": ["async void"]
+    },
+    {
+      "id": "scoped-into-singleton",
+      "prompt": "I have a Singleton `OrderCacheService` in my ASP.NET Core app that occasionally needs to read from the database. Can I just inject my Scoped `OrderDbContext` into its constructor?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct answer says no -- a Scoped OrderDbContext must not be captured directly into a Singleton's constructor/field -- and gives the concrete fix: inject IServiceScopeFactory (or IServiceProvider) into the Singleton and resolve a fresh Scoped OrderDbContext per use via CreateScope(), because a direct capture would pin the first-resolved DbContext instance for the entire application lifetime instead of getting a fresh one per request/operation.",
+          "pass_criteria": [
+            "States plainly that injecting/capturing the Scoped OrderDbContext directly into the Singleton's constructor is wrong.",
+            "Names the concrete fix: inject IServiceScopeFactory (or IServiceProvider) and call CreateScope() to resolve a fresh Scoped OrderDbContext each time it's needed, not once at construction.",
+            "States the concrete consequence of getting this wrong: the captured DbContext instance would be reused for the app's entire lifetime instead of being fresh per operation."
+          ],
+          "fail_criteria": [
+            "Approves injecting/capturing the Scoped OrderDbContext directly into the Singleton's constructor or field, with no per-use scope resolution."
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "No -- don't inject `OrderDbContext` directly into `OrderCacheService`'s constructor. `OrderDbContext` is Scoped, meaning the container hands out a fresh instance per request/scope, but a Singleton is constructed exactly once for the app's whole lifetime; if you capture the Scoped instance at construction time, every later use of that DbContext -- across every request from then on -- reuses whatever instance was live the moment the Singleton was built, which is both wrong (stale state, no per-request isolation) and eventually throws once that DbContext is disposed at the end of its original scope. The fix is to inject `IServiceScopeFactory` into `OrderCacheService` instead, and whenever it actually needs to hit the database, call `using var scope = scopeFactory.CreateScope();` and resolve `OrderDbContext` from `scope.ServiceProvider` right there -- that gives you a properly-scoped, disposed-when-done instance each time, with no lifetime mismatch.",
+        "known_wrong": "Sure, just add `OrderDbContext` as a constructor parameter on `OrderCacheService` like any other dependency -- the DI container will resolve it and inject it same as it would for a Scoped or Transient service. It's a bit of an edge case with the lifetimes technically being different, but in practice it usually works fine since the container doesn't stop you from doing it, and it saves you from having to bring in `IServiceScopeFactory` just for one occasional database read.",
+        "vague": "That's a lifetime mismatch you'll want to handle carefully -- make sure the database access in the Singleton is set up the right way.",
+        "subtle_wrong": "Technically you can register `OrderDbContext` as Scoped and still take it as a constructor parameter on the Singleton -- the container will just resolve it once at startup and hand `OrderCacheService` that instance, and since it's only used for occasional reads rather than every request, the staleness usually isn't a big deal in practice. If you want to be a bit safer you could add a comment noting the DbContext is effectively long-lived here, but a full `IServiceScopeFactory`/`CreateScope()` setup is probably more machinery than this occasional-read case needs."
+      }
+    }
+  ]
+}

package/src/gdskills/bundled/stacks/csharp-dotnet/skills/dotnet-testing/SKILL.md

@@ -0,0 +1,130 @@
+---
+name: dotnet-testing
+description: "Use when a C#/.NET test project needs writing, extending, or fixing -- xUnit/NUnit Fact/Theory and InlineData/TestCase tables, async test methods, and disciplined Moq/NSubstitute mocking that stubs external seams (HTTP, repository, clock) rather than internal collaborators."
+triggers:
+  - "write xUnit tests for this C# class"
+  - "add Theory/InlineData cases for this method"
+  - "fix this failing dotnet test"
+  - "mock this HTTP client with Moq"
+  - "write async test methods for this service"
+  - "add NUnit TestCase coverage for this validator"
+metadata:
+  origin: authored
+  category: test
+  version: "1.0.0"
+  compatible_harnesses: "claude,codex,cursor,zed,opencode"
+license: "MIT"
+---
+
+# .NET testing
+
+Write, extend, or fix a C#/.NET test project's xUnit/NUnit test suite:
+`Fact`/`Theory` (or `Test`/`TestCase`) structure, async test methods, and
+disciplined mocking with Moq/NSubstitute. `rules/testing.mdc` carries the
+full rule set this skill's checklist is built from — read it, not just
+this summary, before writing tests.
+
+## Workflow
+
+### Step 1: Discover the project's test conventions
+
+1. Identify the test framework already in use (xUnit vs NUnit) from the
+   test project's package references — match it; do not introduce a
+   second framework.
+2. Find the layout: a mirrored `*.Tests` project, existing naming
+   pattern (`MethodName_Scenario_ExpectedResult`), and whether
+   FluentAssertions or the framework's own `Assert` is already the house
+   style.
+3. Read 1-2 neighboring test files for: how mocks are constructed (Moq
+   vs NSubstitute), which layer they mock at (a repository interface? an
+   `HttpClient` wrapper?), and any shared fixture
+   (`IClassFixture<T>`/`WebApplicationFactory<TEntryPoint>`) already in
+   use.
+
+### Step 2: Plan test cases
+
+**Methods:** happy path, edge cases (null/empty/default-value inputs),
+exception cases (assert the specific exception type and, where relevant,
+its message/property), boundary values.
+
+**Table-driven:** use `[Theory]`+`[InlineData(...)]` (xUnit) or
+`[Test]`+`[TestCase(...)]` (NUnit) for one method exercised across
+several input/expected-output pairs; reach for `[MemberData]`/a
+`TestCaseSource` when a case needs a non-primitive argument.
+
+**Async code:** a test method covering `async` production code is
+itself `async Task`, never `async void`.
+
+**Mocking boundary (the part most likely to go wrong):** identify which
+collaborators are external seams (HTTP client, repository/database,
+clock, message publisher) — those get mocked. Anything that is the unit
+under test's own internal logic, split into a private helper or another
+method of the same class for readability, is exercised for real, not
+mocked out.
+
+### Step 3: Write
+
+1. Create/extend the test file at the project's own convention path
+   (mirrored `*.Tests` project, matching namespace).
+2. Construct mocks only for the external seam(s) identified in Step 2,
+   via `Mock<IThing>` (Moq) or `Substitute.For<IThing>()` (NSubstitute).
+3. Use `[Theory]`/`[TestCase]` tables for multi-case coverage instead of
+   copy-pasted near-identical test methods.
+4. Await the call under test in every async test; never block with
+   `.Result`/`.Wait()`.
+5. Verify a mock interaction (`mock.Verify(...)`) only when the
+   occurrence itself is part of the contract being tested.
+
+### Step 4: Run and fix
+
+```bash
+dotnet test
+```
+
+Fix failing tests (max 3 iterations) — fix the test, not the source
+under test, unless the test itself has correctly caught a real bug (say
+so in the report rather than silently changing production code).
+
+### Step 5: Report
+
+```
+Generated: src/Orders.Tests/OrderServiceTests.cs
+  - 7 test cases (4 via Theory/InlineData), all passing
+  - Mocked IOrderRepository (external seam); OrderService's own
+    validation logic exercised directly, not mocked
+```
+
+## Rules
+
+- ALWAYS match the project's existing framework, naming, and assertion
+  conventions found in Step 1, not a different project's style.
+- NEVER mock an internal collaborator that is part of what the test is
+  meant to verify — only mock a genuine external seam (HTTP, database,
+  filesystem, clock, message bus).
+- NEVER use `async void` for a test method, or block on `.Result`/
+  `.Wait()` instead of `await`ing the call under test.
+- NEVER synchronize with `Thread.Sleep`/`Task.Delay` to wait for
+  background/async work — await the real `Task` or a real
+  synchronization primitive.
+
+## Red Flags
+
+| Rationalization | Why it is wrong |
+|---|---|
+| "I'll mock the private validation helper too, it's easier than setting up real inputs" | That helper is part of the unit under test; mocking it proves only that your mock returns what you told it to, not that the real logic works |
+| "I'll write this test method as `async void`, it's simpler" | The test runner cannot await it, so a failing assertion or thrown exception inside it is silently lost instead of failing the test |
+| "I'll add a short `Task.Delay(200)` so the background operation finishes before I assert" | Non-deterministic and flaky under load; await the actual `Task` or a real completion signal instead |
+| "I'll just check `Assert.NotNull(result)` for the error case instead of the specific exception type" | Loses exactly which failure occurred; assert the specific exception type (and relevant properties/message) so a regression in *which* error occurs is caught |
+
+## Verification
+
+Do not report the work done until all of the following hold:
+
+- The test file sits at the project's own convention path, matching the
+  framework and naming style read in Step 1.
+- `dotnet test` exits 0 with every generated test passing.
+- Every mock constructed in the new/changed tests is for a genuine
+  external seam, not an internal collaborator of the unit under test.
+- `git status` shows only test files added or modified; no source file
+  under test changed (unless a real bug the test caught was fixed and
+  called out explicitly in the report).