Skip to content

Instantly share code, notes, and snippets.

@iannuttall
Created August 18, 2026 12:18
Show Gist options
  • Select an option

  • Save iannuttall/dbcbd1bfd394a69de90a4ca1596b5f9c to your computer and use it in GitHub Desktop.

Select an option

Save iannuttall/dbcbd1bfd394a69de90a4ca1596b5f9c to your computer and use it in GitHub Desktop.
cull-tests skill: delete agent slop tests, keep ones that would survive a rebuild
name cull-tests
description Cull tests that do not protect behaviour. Use when the user says tests are slop, agents wrote too many tests, tests only check that text exists, or they want a suite an agent could rebuild the product against.

Cull tests

Agents pad test suites. They write tests that confirm a feature exists, that a type already proves, that a button is on the page, or that a mocked API still returns the mock. Those tests pass forever and catch nothing. This skill deletes them and keeps the ones that would still fail if someone rewrote the product from scratch.

The starting cull list is from Howaboua. The bar is Ian's: if you handed only the surviving tests to an agent and said "rebuild this," would it ship the real product?

Do this

  1. List the test files you will touch. Do not scan the whole monorepo unless asked.
  2. For each test, name the behaviour it would catch if that behaviour broke. If you cannot name one in a sentence, it is a delete.
  3. Show a kill list and a keep list before you edit. Wait if the user wants to review. Otherwise delete the kill list and stop.
  4. Do not rewrite the kept tests in the same pass. Do not add new tests unless the user asked for replacements.

Delete

  • Existence tests. "The route exists." "The command is registered." "The component renders." If the only assertion is that something is present, delete it.
  • Typecheck tests. If TypeScript or the compiler already fails when the type is wrong, the test is noise.
  • Provider-shape tests. Tests that replay a mocked Discord / Stripe / model-provider payload and assert the mock. The real API can change tomorrow. Keep a thin adapter contract if you must; delete the ones that freeze the vendor's JSON.
  • Feature-not-contract tests. "User can open settings" with no assertion about what settings do. Test the contract (input → output, permission, error, data written) not the feature name.
  • UI/UX chrome. Snapshot of copy, class names, icon presence, "/command is in the menu." Cull heavily. One journey test that a real user path works is enough.

Keep

  • A test that fails if a rebuild drops a user-facing behaviour.
  • A test whose expected value comes from a spec, a real example, or a known-good literal — not from reading the implementation.
  • A test at a public seam (HTTP handler, CLI, domain function), not a private helper.
  • Adapter tests only for your interface ("we send an amount and an id"), never for the vendor's current field names.

Anti-patterns while culling

  • Replacing a deleted test with a different existence test.
  • Keeping a test because "coverage will drop."
  • Mocking the system under test and asserting the mock was called.
  • Deleting a test you do not understand. Mark it // cull?: name the behaviour or delete and ask.

When you are done

Report: files touched, tests deleted, tests kept, and one sentence on what an agent could still rebuild from the remaining suite.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment