test-hunter

Audits new or changed Go tests to flag wasteful, tautological, and redundant test cases.

54|6|Updated Jan 7, 2026
One-click install
npx skills add https://github.com/schmitthub/clawker --skill test-hunter-schmitthub
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: test-hunter
Source: https://github.com/schmitthub/clawker/tree/main/.agents/skills/test-hunter
Command: npx skills add https://github.com/schmitthub/clawker --skill test-hunter-schmitthub

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? AI agents and developers often generate large volumes of Go tests that look productive but detect no real production defects, creating false confidence, slowing CI, and adding maintenance burden. This Skill performs an adversarial audit of new or changed tests to identify which ones fail to justify their existence. ## Core Features & Use Cases - Six-smell classification: Detects self-serving, tautological, linter-replaceable, redundant, phantom-coverage, and integration-obvious tests, each with a DELETE, REWRITE, or MERGE verdict. - Project-aware auditing: Loads the Clawker test infrastructure context (mocks, fakes, testenv, E2E harness) before reviewing, and flags tests that ignore available helpers or bypass the Cobra Factory entrypoint. - Hardcoded-value detection: Traces asserted values back to production code to catch assertions that never exercise real logic, while accepting golden-file and store round-trip patterns. - Use Case: After an agent writes tests for a new CLI command, run the audit to receive a structured report listing each flagged test, its smell category, file location, and a concrete remediation such as replacing a fake-based unit test with an E2E harness test. ## Quick Start Audit the Go tests changed in my current branch against main and report which ones should be deleted, rewritten, or merged.

Frequently Asked Questions about test-hunter

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

FAQPage Schema
How do I audit Go tests for tests that detect no real bugs?▼

Run the audit against new or modified test files identified via git diff. Each test is classified into six smell categories such as tautological, redundant, or phantom coverage, and receives a DELETE, REWRITE, or MERGE verdict with reasoning.

What makes a Go test tautological or worthless?▼

A test is tautological when the asserted value comes directly from a mock return with no transformation by production code in between. If deleting the production code would not fail the test, the test detects no real defect.

Does the audit work with testify, moq mocks, and table-driven tests?▼

Yes, the audit understands testify assert/require, moq-generated mocks, hand-written fakes, and table-driven tests. Redundant table entries exercising the same code path are flagged for merging, while branch-diverse entries are accepted.

When should a Go unit test be replaced with an E2E test?▼

When an integration or E2E failure would immediately and obviously surface the same bug, the unit test is redundant. Docker-adjacent packages get extra scrutiny, with flagged tests requiring E2E coverage as the replacement.

What test patterns are always acceptable in a Go CLI project?▼

Store round-trip tests with real I/O, E2E harness tests with real dependencies, golden-file comparisons, error-path tests using errors.Is, and Cobra command tests wired through a Factory struct literal are always acceptable.