cull-tests

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.