agentsclimarketplace

Failing test first

Skill alinafe82/cognitive-deadlift/skills/failing-test-first

AI coding skills, hooks, and plugins that keep developers thinking instead of autopiloting

Install
npx -y skills add alinafe82/cognitive-deadlift --skill failing-test-first

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

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.

SKILL.md

3.1 KB, as published. Nobody here has run it

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

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.

Quality Bar

A good result includes a command that failed before the change and passed after the change, plus a clear explanation of what behavior the test proves.

Examples

Simple case: a parser accepts invalid empty input. The skill should create or identify a test that fails on empty input before changing parser code.

Complex case: a retry loop double-submits payments. The skill should create a failing integration or boundary test proving only one payment side effect occurs.

See examples/simple.md and examples/edge-case.md.

Failure Modes

  • No test framework: create the smallest repeatable script or manual command and state its limits.
  • Flaky failure: isolate the smallest deterministic signal before changing code.
  • Tests fail for unrelated reasons: record the baseline failure and avoid claiming the fix passed.
  • Permissions missing: ask for the command or log output needed to reproduce.

Safety And Privacy

Do not use real credentials, payment data, medical records, customer records, or production-only endpoints in tests. Use fixtures or redacted examples.

Anti-Slop Rules

  • Do not write the fix before defining the failing signal.
  • Do not claim a test failed or passed unless it was run.
  • Do not test private internals when public behavior can prove the fix.
  • Do not stop at the happy path if the risk is an edge case.

Gives 0 of the 12 instructions most tdd skills give

Counted across 439 of the 443 authors here whose files we hold, read 2026-08-06

  • write minimal code to pass the testin 302 of 439, across 218 files
  • write a failing test firstin 176 of 439, across 112 files
  • refactor code only after tests passin 171 of 439, across 101 files
  • watch the test fail before writing codein 142 of 439, across 93 files
  • test one behavior per testin 106 of 439, across 44 files
  • refactor code while keeping tests greenin 99 of 439, across 86 files
  • delete code written before testsin 98 of 439, across 54 files
  • run tests after each refactor stepin 85 of 439, across 54 files
  • Use real code instead of mocks unless unavoidablein 64 of 439, across 21 files
  • confirm the test fails for the right reasonin 64 of 439, across 60 files
  • reproduce bugs with a test before fixingin 53 of 439, across 36 files
  • write tests before implementationin 48 of 439, across 39 files

Said here and by no other author read

  • identify the smallest behavior that should fail
  • use an existing test harness when available
  • create a repeatable command if no harness exists
  • rerun the failing signal and regression checks
  • isolate deterministic signals before changing code
  • record baseline failures when tests fail for unrelated reasons

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.