assertion-audit

Audits test suites for assertions that pin limitations or pass for the wrong reason.

Updated Feb 17, 2026
One-click install
npx skills add https://github.com/semantic-praxis/barwise --skill assertion-audit-semantic-praxis
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: assertion-audit
Source: https://github.com/semantic-praxis/barwise/tree/main/.claude/skills/assertion-audit
Command: npx skills add https://github.com/semantic-praxis/barwise --skill assertion-audit-semantic-praxis

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Test suites can stay green while certifying bugs: tests that pin temporary limitations as if they were requirements, and assertions that pass regardless of what production code does. This Skill provides authoring rules that prevent both defect classes and a three-pass audit method that finds the ones already in your suite. ## Core Features & Use Cases - Authoring rules: Name refusal tests by why input is invalid rather than what is currently built, discriminate fixture-supplied strings from production error strings, and verify flags are wired end-to-end rather than merely parsed. - Three-pass audit method: Pass 1 greps for limitation-pinned refusals, Pass 2 mutates producers to find fixture-asserting tests, and Pass 3 mutates subjects to expose checks that cannot fail. - Ratchet deliverable: Convert findings into a baseline script with a --check mode wired into CI so fixed defects cannot silently return. - Use Case: After adding a capability to a CLI command or MCP tool, run the audit to find and delete the stale tests that still assert the old refusal, then add a mutation-killing test that proves the new wiring. ## Quick Start Audit the test suite for assertions that pin limitations or cannot fail, and report findings with file and line evidence.

Frequently Asked Questions about assertion-audit

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

FAQPage Schema
How do I write tests for error and refusal behavior correctly?▼

Name refusal tests by why the input is invalid, never by what is currently built. A name containing "yet", "only", or "not supported" pins a limitation; either skip the test or mark it with the issue that will remove it.

How do I find tests that pass but verify nothing?▼

Mutate the producer of a value the test consumes and re-run the suite; a mutation that survives green exposes a fixture-asserting test. For checks whose passes get counted, delete the very thing the check requires and demand failure.

How do I verify a CLI flag is actually wired end-to-end?▼

Asserting --help output or bad-value rejection only proves parsing. Assert the flag's value at the far end, such as reading requests captured by a loopback test server, so the wiring itself is under test.

Why did my mutation testing produce false findings?▼

Common causes are uncommitted fixes lost during revert, stale build artifacts hiding cross-package mutations, and mutations that never actually changed the fixture. Rebuild before testing across packages and verify the mutation took effect.

When should I delete a test that asserts a refusal?▼

Delete it in the same change that adds the capability the refusal denied. The change that adds a capability owns removing tests asserting its absence, otherwise the suite defends outdated behavior as if it were a requirement.