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 for this PR" |
Green CI is in scope for every PR. There is no PR for which red CI is acceptable. |
| "The test must be wrong" |
Maybe. Verify — don't assume. If it really is wrong, fix the test; don't delete or skip it. |
| "Works on my machine / differs from CI" |
Match the environment. That's what lockfiles, containers, and CI configs are for. |
| "I'll fix it in a follow-up" |
Follow-ups don't happen. Fix it now, in this change, before the next bug lands on top. |
What to do
- Reproduce. Re-run the failing command. Capture the full output — exact error, file, line, stack trace.
- Read. Open the failing file and the production code it exercises. Read every line of the error before diagnosing.
- Fix the root cause. Edit the offending code. If the production code is correct and the check is stale (renamed symbol, outdated snapshot, old type), fix the test/lint/type expectation instead. If the failure is a tooling regression, update the dependency or config.
- Re-run the full suite. Not just the one test — the whole failing command. Confirm green before stopping.
Do not:
- Run
git stash, git switch, or any "is this my fault?" verification
- Add a skip / xfail /
// eslint-disable / # type: ignore without explicit user OK
- Comment out the failing test or assertion
- Lower the strictness of the check
- Rebase/squash/force-push to make the failure disappear from the diff
If you genuinely cannot fix it
Some failures are outside the current scope (e.g. an integration test that needs a network resource you don't have, or a fix that would require changes the user hasn't authorized).
- State the root cause and what you tried.
- Propose a concrete fix.
- Ask the user whether to defer, suppress (with their approval of the exact suppression), or keep investigating.
The user — not you — makes that call.
Escalation
After 2 failed fix attempts, invoke /second-opinion. After 4, invoke /hard-fix. Don't keep retrying the same approach.
Examples
typecheck error in a file you didn't touch.
Wrong: "Pre-existing — my changes only touched src/api/." Stop.
Right: Read the error. Fix it. Re-run tsc. Green.
A flaky-looking test.
Wrong: "Flaky — unrelated to this PR."
Right: Read the test. Find the race / shared state / missing await. Fix it. If you can't, escalate to the user with what you checked.
Lint warning in legacy code.
Wrong: "Pre-existing in legacy code, ignoring."
Right: Read the warning. Fix it (usually three lines). If it's a stylistic rule that genuinely doesn't apply, ask the user before adding a scoped override.
User-approved exceptions
If the user has explicitly told you in this session that a specific failure is OK to leave alone ("yeah, skip the e2e suite, staging is down"), honor it — and quote their words when you do. Do not infer permission from silence.
1---2name: pre-existing3description: 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`.4---56<!-- Generated from https://github.com/nielsmadan/agentic-coding — edits here are overwritten. -->78# Pre-Existing910**Don't investigate whether it's pre-existing. Just fix it.**1112We 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.1314## When to invoke1516Whenever you are about to:1718- Call a failure "pre-existing", "already broken", "already failing", "was already there", or "not introduced by my changes"19- Call a test "flaky", "unrelated", "intermittent", or "environmental"20- Suggest the user "skip", "ignore", or "move on past" a test, lint, type, build, or CI failure21- Use `git diff` / `git blame` / `git stash` to argue a failure isn't your fault22- Stop a turn while any check is red2324Also when the **user** types `/pre-existing`.2526## Common rationalizations2728If you catch yourself thinking any of these, the answer is in the right column.2930| Rationalization | Reality |31|---|---|32| "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. |33| "`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. |34| "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. |35| "Out of scope for this PR" | Green CI is in scope for every PR. There is no PR for which red CI is acceptable. |36| "The test must be wrong" | Maybe. Verify — don't assume. If it really is wrong, fix the test; don't delete or skip it. |37| "Works on my machine / differs from CI" | Match the environment. That's what lockfiles, containers, and CI configs are for. |38| "I'll fix it in a follow-up" | Follow-ups don't happen. Fix it now, in this change, before the next bug lands on top. |3940## What to do41421. **Reproduce.** Re-run the failing command. Capture the full output — exact error, file, line, stack trace.432. **Read.** Open the failing file and the production code it exercises. Read every line of the error before diagnosing.443. **Fix the root cause.** Edit the offending code. If the production code is correct and the check is stale (renamed symbol, outdated snapshot, old type), fix the test/lint/type expectation instead. If the failure is a tooling regression, update the dependency or config.454. **Re-run the full suite.** Not just the one test — the whole failing command. Confirm green before stopping.4647Do **not**:48- Run `git stash`, `git switch`, or any "is this my fault?" verification49- Add a skip / xfail / `// eslint-disable` / `# type: ignore` without explicit user OK50- Comment out the failing test or assertion51- Lower the strictness of the check52- Rebase/squash/force-push to make the failure disappear from the diff5354## If you genuinely cannot fix it5556Some failures are outside the current scope (e.g. an integration test that needs a network resource you don't have, or a fix that would require changes the user hasn't authorized).57581. State the root cause and what you tried.592. Propose a concrete fix.603. Ask the user whether to defer, suppress (with their approval of the exact suppression), or keep investigating.6162The user — not you — makes that call.6364## Escalation6566After 2 failed fix attempts, invoke `/second-opinion`. After 4, invoke `/hard-fix`. Don't keep retrying the same approach.6768## Examples6970**typecheck error in a file you didn't touch.**71Wrong: "Pre-existing — my changes only touched `src/api/`." Stop.72Right: Read the error. Fix it. Re-run `tsc`. Green.7374**A flaky-looking test.**75Wrong: "Flaky — unrelated to this PR."76Right: Read the test. Find the race / shared state / missing await. Fix it. If you can't, escalate to the user with what you checked.7778**Lint warning in legacy code.**79Wrong: "Pre-existing in legacy code, ignoring."80Right: Read the warning. Fix it (usually three lines). If it's a stylistic rule that genuinely doesn't apply, ask the user before adding a scoped override.8182## User-approved exceptions8384If the user has explicitly told you in this session that a specific failure is OK to leave alone ("yeah, skip the e2e suite, staging is down"), honor it — and quote their words when you do. Do not infer permission from silence.
nielsmadan