
Test Audit
FreeStreamline your test writing and auditing process.
Free · Opens the source repo
What Test Audit does
Test Audit is a skill designed to enhance the quality and efficiency of your testing workflows. It operates in two distinct modes: Authoring mode and Audit mode. In Authoring mode, the skill acts as a gatekeeper for new or modified tests, ensuring that every addition is justified by a clear rationale. Users must answer four critical questions before adding a test, which helps to prevent unnecessary duplication and encourages the creation of meaningful tests that protect observable behavior rather than implementation details.
In Audit mode, Test Audit provides a systematic approach to reviewing existing tests. It allows developers to conduct focused sweeps of their test suites, identifying tests that may not provide sufficient value or that are overly coupled to implementation details. This mode emphasizes maintaining high confidence in test coverage without simply deleting tests for the sake of reducing count. Instead, it encourages thoughtful consideration of each test's purpose and its relationship to the codebase.
The skill is particularly beneficial for teams that prioritize robust testing practices and want to maintain a clean and efficient test suite. By using Test Audit, teams can ensure that their tests are not only comprehensive but also relevant, reducing maintenance costs and improving overall code quality. This skill is suitable for developers and QA engineers who are involved in writing, reviewing, or maintaining tests in a collaborative environment.
Overall, Test Audit serves as a valuable tool for enforcing best practices in testing, helping teams to create a more effective and manageable testing strategy that aligns with their development goals.
When to use it
Use this skill when writing new tests or auditing existing ones to maintain a high-quality test suite.
When not to use it
This skill may not be suitable for teams that do not have a structured testing process or for projects with minimal testing requirements.
What you can build with it
New Test Creation
When creating new tests, use Test Audit to ensure each test serves a meaningful purpose and is not a duplicate.
Test Suite Review
During a review of your test suite, employ Audit mode to identify and assess tests that may be redundant or unnecessary.
Team Collaboration
In a collaborative development environment, leverage Test Audit to maintain high standards for test quality and relevance.
How to install Test Audit
View source1. Install with the skills CLI
npx skills add openclaw/openclaw/test-audit --agent claude-code2. Or install it manually
Download the skill folder and drop it into ~/.claude/skills/ for all projects, or .claude/skills/ to scope it to one repo. Restart Claude Code so it picks up the new skill.
Anthropic's agentic coding CLI, and the reference implementation of Agent Skills. Drop a skill folder into ~/.claude/skills and Claude Code loads it automatically whenever a task matches the skill's description. Claude Code docs
Inside SKILL.md
Written by openclawTest Audit
Two modes, one value bar. Authoring mode gates every new or changed test at write time. Audit mode runs focused sweeps of tests that re-assert source, duplicate stronger proof, couple behavior to implementation, or keep test-only production seams alive. Continue broad audits as separate coherent follow-up PRs; optimize for confidence, not deletion count.
Authoring gate
Before adding any test, answer four questions; a missing answer means do not add it yet:
- What observable behavior, invariant, or independent contract does it protect?
- What credible regression makes it fail?
- Why does existing coverage not already catch that failure? Prefer extending a table-driven case or shared fixture over a near-duplicate test.
- Does it need a production seam (export, flag, wrapper, injection hook) that no production caller needs? If yes, move the test to the real boundary instead.
A test that would break under behavior-preserving refactoring is asserting implementation, not behavior; rewrite it at the owning boundary before landing it.
Bug regression tests must fail on the pre-fix code for the intended reason and pass after the owner-boundary repair. A regression test that never demonstrably failed proves the mock, not the fix.
Value bar
Tests justify their maintenance cost by protecting behavior, a credible regression, or an independently meaningful contract. A test that must change for behavior-preserving source reorganization is suspect, not automatically deletable.
Before judging a candidate, read the complete test and production owner, its
entry point, callers, callees, sibling implementations, overlapping tests, CI
routing, and relevant history. Read root and scoped AGENTS.md files first.
When the test claims dependency-backed behavior, inspect the dependency source
or types directly.
Discovery
Keep discovery read-only and report evidence before editing. For broad scope, run parallel discovery lanes when available:
- core and packages (
src/,packages/); - plugins (
extensions/); - UI, apps, scripts, and tooling;
- a cross-cutting pattern sweep.
Prefer a few high-confidence candidates over a large speculative inventory. Look for:
- assertion-free coverage probes;
- self-comparisons and identity copiers;
- copied fixtures, inventories, manifests, or export lists;
- exact source, import, or string greps;
- private predicate or call-shape tests duplicated at real boundaries;
- duplicate invocations of the same contract;
- provider-local replays of shared helpers;
- tests whose only purpose is preserving test-only exports, globals, or wrappers;
- dead production code whose only callers are tests.
Retention bar
Keep a test when it independently enforces a public API, plugin SDK, protocol, config, migration, storage, security, platform, default, prompt-byte, generated cross-language, package, release, or architecture contract. Also keep:
- call ordering when order is observable behavior;
- regressions with a credible failure mode;
- source inspection when it is the cheapest independent guard.
Static or slow is not a deletion reason. A test that resembles implementation may still be the independent contract; prove otherwise before removing it.
Candidate evidence
Record every field below before editing. A missing field means the candidate is not ready for deletion:
- exact test name and location;
- what failure it can actually detect;
- non-test callers of the covered production or support seam;
- stronger remaining owner-boundary proof, or why no proof is needed;
- relevant history and the reason the test or seam exists;
- production or test-support deletion unlocked;
- risk and the focused validation command.
Edit shape
Choose one coherent owner-boundary batch. Delete obsolete test-only exports, globals, wrappers, and dead production paths instead of preserving aliases. Move retained regressions to their canonical owners. Consolidate repeated package or dependency assertions into one generic contract.
Prefer net-negative production LOC. Do not add replacement tests that restate the same implementation, and do not convert uncertain candidates into cleanup to increase deletion counts.
Validation
Never edit source or tests while Vitest is running in the checkout. Follow
$openclaw-testing; route heavy proof through its $crabbox rules.
- Run the smallest owner and sibling tests with
node scripts/run-vitest.mjs <path-or-filter>. - For removed source greps or plan assertions, run the executable script or dry-run that owns the real contract.
- Run targeted formatting, then
git diff --check. - Classify with
node scripts/check-changed.mjs --dry-run -- <changed-paths>, then run the actual changed gate required by repository policy. - Inspect
git diff --numstat; report production/tooling separately from tests and test support. - After final audit edits, run mandatory
$autoreview.
Landing and continuation
Commit, push, open a PR, or land only when authorized. Use
$openclaw-pr-maintainer and the repository scripts/pr flow. Land one
coherent PR at a time; after landing, refresh from current main and rerun
read-only discovery for the next high-confidence batch.
Handoff
Report:
- root cause and removed low-value categories;
- production owner simplifications;
- retained false positives and why they remain valuable;
- focused and full proof actually run;
- production versus test LOC;
- PR and merge state;
- named follow-ups.
Frequently asked questions about Test Audit
Similar skills
Quality Playbook Generator
Run comprehensive quality audits on any codebase.
PR Draft Summary
Automate PR summary generation for openai-agents-python.
Final Release Review
Streamline your release candidate audits with ease.
Unit Test Vue Pinia
Efficiently write and review unit tests for Vue 3 applications.
Slang Shader Expert
Optimize and integrate Slang shaders with ease.
Telemetry Standards
Ensure consistent event tracking in Supabase Studio.
