agentleFS
Cor-IncorporatedCor-Incorporated/claude-code-skills/skills/test-falsify/SKILL.md

test-falsify

Skill5 starsChanged 2 months agoMITView on GitHub

Verify that tests actually detect the bugs they claim to detect. Checks if assertions would fail when the declared bug exists -- catches 'tests that pass even when broken' (PR #321 incident). Invoke with /test-falsify or auto-trigger after E2E/integration test creation. Use when: reviewing test quality, validating regression tests, reporting test results in PRs, or when a test seems too permissive. Do NOT use for: unit test generation, test coverage analysis, performance benchmarking, or linting.

The file

We split this skill into the rules it gives an agent

6 rules. About 0 are common, 5 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈5

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Verify that tests fail when their declared bugs exist.

    line 9
  2. Distinctive:

    After creating/modifying E2E or integration tests

    line 13
  3. Distinctive:

    Before reporting test results in a PR

    line 14
  4. Very specific:

    When /test-falsify is explicitly invoked

    line 15
  5. Distinctive:

    When a test looks suspiciously permissive

    line 16
  6. Distinctive:

    User requirements: check conversation history for the original test request.

    line 26

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Test Falsifiability Verifier

Verify that tests fail when their declared bugs exist. A test that passes with the bug present is worthless.

When to Run

  • After creating/modifying E2E or integration tests
  • Before reporting test results in a PR
  • When /test-falsify is explicitly invoked
  • When a test looks suspiciously permissive

Execution

Phase 1: Extract Intent

From the target test file, extract:

  1. Bug declarations: keywords Bug, detect, regression, fix in docstrings/comments.
  2. Test name intent: test_long_conversation_natural_ending -> validates "natural ending".
  3. User requirements: check conversation history for the original test request.
<important if="reviewing test quality or validating whether assertions catch the declared bug"> ### Phase 2: Analyze Assertions

Evaluate each assertion against three checks:

Check 1: Falsifiability (CRITICAL)

Would this assertion fail if the declared bug exists?

PatternVerdictExample
Bug present -> assertion failsVALIDassert turn_count != 37
Bug present -> might passWEAKassert turn_count >= 18 (37 >= 18 passes)
Bug present -> always passesINVALIDassert result.completed (completes at 37 too)

Check 2: Uniformity Detection

Does the test verify that different inputs produce different outputs?

PatternVerdict
Multiple inputs + variance checkVALID
Single input + lower bound onlyINVALID
Parametrize + per-case lower boundWEAK (uniform results still pass)

Check 3: Domain Consistency

Do test results contradict domain common sense?

Refer to references/domain-checklist.md for domain-specific checks. </important>

<important if="improving weak or invalid test assertions"> ### Phase 3: Propose Improvements

Provide concrete assertion additions:

# Variance check: different answers produce different turn counts
results = [run(verbose_answers), run(brief_answers), run(mixed_answers)]
turn_counts = [r.turn_count for r in results]
assert max(turn_counts) - min(turn_counts) >= 3, "Fixed turn count = ignoring answers"

# Upper bound: reject known-bad fixed value
assert result.turn_count < 35, "37-turn fixed pattern detected"

# Uniformity rejection: not all models produce identical results
followup_counts = [r.followup_count for r in model_results]
assert len(set(followup_counts)) > 1, "All models identical = mechanical"

# Domain-specific: detailed answers should end sooner
verbose = run(very_detailed_answers)
brief = run(minimal_answers)
assert verbose.turn_count < brief.turn_count, "Not evaluating answer quality"
</important><important if="generating a falsifiability review report for a PR or test audit"> ### Phase 4: Report
## Falsifiability Review

### Target: `path/to/test_file.py`

### Intent-Assertion Alignment
| # | Declared Intent | Assertion | Fails with bug? | Verdict |
|---|----------------|-----------|-----------------|---------|
| 1 | Bug 3: 37-turn fix | turn_count >= 18 | No (37>=18) | INVALID |
| 2 | Natural ending | has_farewell() | Yes | WEAK |

### Uniformity Check
- Multiple input patterns: YES / **NO**
- Variance verification: YES / **NO**

### Domain Consistency
- [Any domain-specific anomalies]

### Recommended Fixes
1. [Specific assertion to add]
2. [Test case to add]
</important><important if="encountering edge cases during falsifiability analysis"> ## Error Handling
SituationAction
No docstring/comment declaring intentInfer from test name; flag as "intent undocumented"
Cannot determine if bug makes assertion failRun mental simulation with bug present; if uncertain, mark WEAK
All assertions are INVALIDRecommend rewrite with concrete examples; do not approve
Test has no assertionsFlag as INVALID -- assertion-free test proves nothing
</important>

References

  • references/domain-checklist.md -- Domain-specific test consistency checks

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.