Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →dotnet/code-testing-agent
MANDATORY ENTRY POINT for generating or writing tests. Invoke this skill before editing files whenever the user asks to generate tests, write/add unit tests, scaffold a test project or suite, improve/achieve coverage, extend an existing suite to cover an untested method, or test an app, API, service, module, library, or package. Applies to a single function, method or file as much as to a whole project — scope changes how much of the workflow runs, never whether the skill applies. Invoke it when
Passed 8 of 14 test cases with the skill, and 6 of 14 without it.
and 3 more in the full report
6 fixed7 passed either way7 still failing2 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.
In a multi-file TypeScript repository, what tool should be invoked to automatically pair source files with test files and list untested source modules?
| Checked | Without skill | With skill |
|---|---|---|
| The response specifies calling find-untested-sources to discover untested source paths. | Missed | Passed |
The instructions your model reads when the skill loads.
An AI-powered skill that generates comprehensive, workable unit tests for any programming language using a coordinated multi-agent pipeline.
Classify scope before editing:
research.md and plan.md in a resolved
non-stageable <TESTAGENT_DIR> before implementation, then status.md there
after the final test-quality review. If these files are absent, the broad
workflow is incomplete.For either scope, run the narrowest relevant test command to a clean exit and
finish with a compact Requirement | Evidence table. Each requested behavior
must cite an exact test name; validation rows cite the successful command.
For focused work, "no intermediate state files" changes only the process, not the
final evidence contract.
Intermediate state files are internal working data, never deliverables. Keep
<TESTAGENT_DIR> non-stageable, never place it or its files in
version-controlled workspace content, and never modify .gitignore to hide
them.
Treat completeness as a requirement matrix, not a test-count target. Give every independently requested state, boundary, error path, or interaction its own concrete assertion. Combine cases only when one execution genuinely proves the whole requested combination; do not let a parameterized happy-path case stand in for an empty state, invalid discriminator, or before/at/after boundary. For broad requests that name several production modules or layers, give each named module direct tests for its non-trivial public behavior. Cross-module tests prove composition, but do not substitute for the requested module-level coverage. Judge breadth by the behavior matrix, never by matching or exceeding a raw test count.
test cases passed, vs 6 / 14 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.