← ClaudeAtlas

failing-test-firstlisted

Require a failing signal before bug fixes or behavior changes. Use when fixing a bug, adding behavior, changing edge cases, or reviewing AI code that lacks proof. NOT for docs-only edits, generated snapshots, or emergency hotfixes with a tracked follow-up test.
alinafe82/cognitive-deadlift · ★ 0 · AI & Automation · score 70
Install: claude install-skill alinafe82/cognitive-deadlift
# Failing Test First ## Purpose Turn a fix from a guess into a red-green feedback loop. ## Preserves Behavioral proof and test design. ## Required Evidence - Bug description or desired behavior. - Smallest failing signal available. - Command or repeatable step that can prove the failure and the fix. ## Failure Signs - The fix is written before the failing signal is defined. - Test results are claimed without command output. - The test covers only the happy path while the bug is an edge case. ## When To Use - A bug fix is requested. - New behavior needs acceptance proof. - AI proposes a code change without showing a failing signal. - A regression could return silently. ## When Not To Use - Documentation-only edits. - Snapshot or lockfile churn with separate validation. - Emergency hotfixes where restoration is more urgent and a follow-up test is tracked. ## Inputs Expected - Bug description or desired behavior. - Existing test command if known. - Relevant files, reproduction steps, logs, or failing user workflow. ## Output Expected ```md Failing signal: Command: Expected failure: Fix boundary: Passing signal: Regression checks: ``` ## Process 1. Identify the smallest behavior that should fail before the fix. 2. Use an existing test harness when available. 3. If no harness exists, create a repeatable command or script. 4. Run the failing signal and capture the failure. 5. Implement the smallest fix. 6. Re-run the failing signal and nearby regression checks. #