flaky-test-detectivelisted

# Flaky Test Detective Catch the test that passes and fails on the *same code* — and rewrite it so it's deterministic, before it trains your team to ignore red builds. A flaky test is worse than no test. It fails once, someone reruns CI, it passes, and everyone learns that red doesn't mean broken. Soon a *real* regression sails through behind a "just rerun it." The cause is almost never the code under test — it's a hidden dependency on something the test doesn't control: the clock, the random seed, the order tests run in, a shared row in the database, a real network call, the iteration order of a map. This skill finds that hidden input, explains why it makes the test non-deterministic, and rewrites the test to control it. ## When to use this - A test **fails intermittently** — red on one run, green on the next, no code change. - A test is **green locally but red in CI** (or vice versa), or only fails under parallelism or a particular order. - Someone says *"just rerun it,"* *"it's flaky,"* or *"passes on retry."* - You are **writing or reviewing** a test and want to catch non-determinism before it's committed. - You want to **harden a suite** — find the latent flakiness before it fires. If a test fails **every** time, it's not flaky — it's a real failure or a genuine bug; fix the code, don't stabilize the test. And never "fix" flakiness by adding a retry or a `sleep` that hides it — that buries the signal. The goal is a test that's **deterministic**, not one that's *