hf-test-adequacy

name	hf.test-adequacy
description	Assess whether changed production code has adequate test coverage for functionality, regressions, and edge cases.

Test Adequacy Check

Assess whether changed production code has adequate test coverage. This is a read-only assessment — it does not modify files.

When to Use

• After implementing changes, before committing
• To verify test coverage for new and changed code
• When reviewing a branch for test completeness

Instructions

1. Get the diff of changes on the current branch:

   git diff origin/main...HEAD
   

   If that's empty, fall back to git diff (unstaged) or git diff --cached (staged).

2. Identify all changed or added production files (exclude test files).

3. For each changed production function/method/class, verify:

   • Has a corresponding test — at least one test exercises the new/changed code path
   • Edge cases covered — empty inputs, None values, boundary conditions, error paths
   • Regression safety — if existing behavior changed, tests verify the new behavior
   • No test-only gaps — new test utilities or fixtures are themselves tested if non-trivial

4. Produce structured output:

If coverage is adequate:

TEST_ADEQUACY_RESULT: OK
SUMMARY: All changed code has adequate test coverage

If gaps exist:

TEST_ADEQUACY_RESULT: RETRY
SUMMARY: <comma-separated list of gap categories>
GAPS:
- <production_file:function — what test is missing>

Important

• Do NOT modify any files. This is a read-only assessment.
• Focus on whether production code is tested, not test code style.
• Ignore test file changes when assessing adequacy.
• Be pragmatic: simple getters/setters don't need dedicated tests. Focus on logic, branches, and error paths.

Note: implementer-loop gate also runs a deterministic coverage-delta check

When test-adequacy runs inside the implementer loop (not this interactive slash command), AgentRunner._run_skill additionally runs make coverage 0 after the LLM verdict and overrides a PASS to RETRY if any changed production line has zero coverage hits. This slash command remains read-only and LLM-only; the subprocess coverage check is an implementer-loop-only behaviour.