/audit-tests

/audit-tests finds code in your project that is not thoroughly tested and makes it thoroughly tested. It learns the project's stack, test runner, and existing test style first, measures real coverage (installing the coverage tool if it is missing), triages every source file, then writes tests and verifies the whole suite green. The bar is not "a test exists" - it is every branch, boundary, and adversarial input having a test that fails when it breaks. It is runnable repeatedly: each run finds the next-biggest gap by itself, so no state file is needed.

Install

From your project root, after installing the package (see Getting started):

mkdir -p .claude/skills

ln -s ../../node_modules/@daanvandenbergh/claudekit/skills/ts/audit-tests \
      .claude/skills/audit-tests

Restart Claude Code so it picks up the new skill.

Usage

/audit-tests [module-path or file]

Argument	What it does	Default
module-path or file	Scopes the run to that path.	Omitted - audits the whole in-scope surface and picks the biggest gap.

There are no flags.

What it does

• Learns the project. Reads CLAUDE.md / AGENTS.md / README and the manifest to find the language and test command, the runner and where tests live, the 1-2 strongest existing tests as the house-style reference, the coverage tool, and any import-time config traps.
• Measures. Runs coverage, installing the provider that matches the runner if absent, and configuring it to report every in-scope file - including files no test imports, which otherwise read as absent rather than 0%.
• Triages. Classifies each in-scope file as untested logic, weakly tested, covered indirectly, or nothing to assert, then picks the highest-value target. Views, thin adapters, framework wiring, and type-only files are out of scope by default and reported as skipped, not silently dropped.
• Hunts edge cases. Walks the target against every category in the skill's edge-case checklist - empty and whitespace inputs, boundaries, idempotency, concurrency, and more - and turns each into concrete inputs for that code.
• Writes tests. Follows the existing suite's location, naming, and setup; one behaviour per test, asserting error identity and payload, using the project's real test doubles.
• Verifies. Runs the full test command, the typecheck/lint if there is one, and re-runs coverage. A new test that fails is either a real bug (reported, test kept) or a wrong assumption (test fixed) - never weakened or deleted to reach green.
• Reports. Coverage before and after, files and test counts added, any real bug found, what is still untested and why.

Work is incremental: one gap closed thoroughly and verified, rather than one huge diff across every file.

When to use it

Use /audit-tests when the question is coverage: untested code, missing edge cases, "are we fully tested?". Use /audit instead to run a full phased pass over one module - security, code quality, call-chain logic, and tests together. Use /audit-security for a whole-project security sweep and /audit-deep-logic for bugs in the seams between modules.

Examples

/audit-tests src/billing/pricing.ts

/audit-tests

The first hardens one file. The second audits the whole project and closes its biggest gap; run it again later and it moves to the next one.

Related

• Skills and rules - how the symlink and @-import mechanisms work.
• /audit - the phased per-module audit that includes a test-coverage phase.