Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →dotnet/test-gap-analysis
Performs pseudo-mutation analysis on production code in any language to find gaps in existing tests.
Passed 6 of 11 test cases with the skill, and 5 of 11 without it.
and 3 more in the full report
6 fixed5 passed either way7 still failing4 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 6 test cases the skill fixed. Same model, same prompt, with and without the skill.
We completed a gap audit of `HashUtils.cs` unit tests. All core hashing algorithms, key sizes, and error guards have active assertions, with only a redundant exception message check omitted. How should the assessment report begin?
| Checked | Without skill | With skill |
|---|---|---|
| Leads response with Strong verdict | Missed | Passed |
| Names concrete protected boundaries before listing gaps for Strong suites | Passed | Passed |
The instructions your model reads when the skill loads.
Answer one question: which caller-visible production behaviors could change without an existing test failing? Mutation reasoning is a probe, not the goal. Inventory public outcomes first, then verify only credible gaps.
Discover production and test files from manifests and file types. After a narrow search misses, inspect the current directory broadly before asking for paths.
| Request | Action |
|---|---|
| One component or named risk | Inventory every high-risk public outcome in scope; do not edit production code unless verification was requested |
| General small-component review | Inventory distinct outcomes and report caller-visible gaps from source/assertion mapping |
| Explicit survivor verification | Inventory all requested outcomes; execute one representative observable candidate for each distinct high-risk outcome under verification, then classify it as Survived or Killed |
| Explicit exhaustive audit | Read references/mutation-catalog.md and classify all meaningful candidates |
| Add tests to an existing suite | Analyze first; add tests only for verified survivors or demonstrated no-coverage outcomes |
| Create a new suite | Stop and use code-testing-agent |
When the request names a risk, turn it into a one-line public-outcome allowlist
before reading code. An outcome is not in scope merely because the same method writes it.
For money math, allow computed or returned amounts, rates, tier/boundary
choice, percentage base/order, floors/caps, and rounding; exclude non-monetary
state predicates (including derived booleans), identity, and formatting. Private
code is in scope only to trace an allowed outcome.
Do not expand a focused request into a repository audit, plan artifact, or
dashboard. Use source and tests directly for familiar frameworks. Invoke
test-analysis-extensions only when discovery or assertion semantics are
unclear.
Run the narrowest existing test command once. Choose it from the project
manifest; Microsoft.Testing.Platform executables may require dotnet run.
Confirm tests executed: exit 0 with build-only output is not green. If that one
attempt cannot run the suite, do not troubleshoot the runner or try alternate
test cases passed, vs 5 / 11 without
Published skills whose descriptions closely match this one, with their headline benchmark lift.
More skills from the same source and nearby in the registry, with their headline benchmark lift.