wf-vacuity

Audits existing test suites by mutating implementations and detecting tautological or weak assertions.

Updated May 9, 2026
One-click install
npx skills add https://github.com/23min/aiwf --skill wf-vacuity-23min
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: wf-vacuity
Source: https://github.com/23min/aiwf/tree/main/internal/skills/embedded-rituals/plugins/wf-rituals/skills/wf-vacuity
Command: npx skills add https://github.com/23min/aiwf --skill wf-vacuity-23min

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? A fully-covered test suite can still be vacuous: assertions that pass for the wrong reason, tautological checks, or tests that only exercise the happy path. This is especially risky when the same LLM wrote both the implementation and its tests. This Skill adversarially audits whether a unit's tests can actually fail before you declare the work done. ## Core Features & Use Cases - Mutation probe: Introduces deliberate, realistic bugs (negated guards, off-by-one errors, dropped steps) and confirms at least one test goes red for each, recording surviving mutants as coverage holes. - Tautology and narrowing probe: Reads each assertion for weaknesses such as existence-only checks, over-narrowed inputs, can't-fail properties, and assertions on mocks. - Structured report: Emits a markdown report listing surviving mutants, weak assertions, and clean assertions, routing findings back to the human or to test-strengthening workflows without rewriting tests itself. - Use Case: After an AI assistant generates both a Go module and its tests, run this audit to verify the tests genuinely constrain behavior before proposing the unit for merge. ## Quick Start Ask the assistant to run a vacuity audit on the unit you just finished to confirm its tests would actually catch real bugs.

Frequently Asked Questions about wf-vacuity

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I check if my tests actually test anything?

Run a vacuity audit: deliberately introduce a realistic bug such as a negated guard or off-by-one error, then run the suite. If no test fails, that surviving mutant reveals an assertion gap. Also review each assertion for tautological checks like result != nil.

What is mutation testing and when should I use it?

Mutation testing introduces small deliberate bugs into code to verify tests catch them. Use it after tests pass and before declaring work done, particularly when you distrust an LLM-authored suite. Where tools like Stryker, mutmut, or PIT exist, prefer them over manual probes.

Why is 100% code coverage not enough?

Coverage only proves a line executed, not that an assertion would catch a bug on that line. A suite can be fully covered yet vacuous, with tautological assertions or tests exercising only happy-path inputs where bugs cannot appear.

Can this audit rewrite or fix my weak tests?

No. The audit only reports surviving mutants and weak assertions; strengthening tests is a separate, reviewed change handled by test-driven or property-testing workflows. This separation keeps the audit adversarial rather than self-grading.

What are the limitations of a manual vacuity audit?

The audit is LLM-judged, so a clean report means no weakness was found, not that tests are verified correct. It is a stop-gap for repos without a mutation-testing harness; a real mutation tool provides the stronger, mechanical signal.