← ClaudeAtlas

pre-existinglisted

Fix any test/lint/type/build/CI failure instead of dismissing it as pre-existing, flaky, or unrelated. Triggers on red checks or `/pre-existing`.
nielsmadan/skills · ★ 0 · AI & Automation · score 75
Install: claude install-skill nielsmadan/skills
<!-- Generated from https://github.com/nielsmadan/agentic-coding — edits here are overwritten. --> # Pre-Existing **Don't investigate whether it's pre-existing. Just fix it.** We don't care who broke it, when, or whether your changes caused it. The only acceptable end state is **all checks green**. Skip the forensics. ## When to invoke Whenever you are about to: - Call a failure "pre-existing", "already broken", "already failing", "was already there", or "not introduced by my changes" - Call a test "flaky", "unrelated", "intermittent", or "environmental" - Suggest the user "skip", "ignore", or "move on past" a test, lint, type, build, or CI failure - Use `git diff` / `git blame` / `git stash` to argue a failure isn't your fault - Stop a turn while any check is red Also when the **user** types `/pre-existing`. ## Common rationalizations If you catch yourself thinking any of these, the answer is in the right column. | Rationalization | Reality | |---|---| | "It was failing before my changes" | CI was green at the branch point. If it's red now, something changed — a dep update, a generated file, a type-narrowing edit elsewhere. Bisect. | | "`git diff` doesn't touch this file" | Indirect deps, generated files, transitive type changes, and snapshot drift can break distant checks. The diff is not the blast radius. | | "It's a flaky test" | Known by whom? Link the issue. If you can't, it's not flaky — it's a race or shared-state bug you haven't found yet. | | "Out of scope