Use whenever fixing a failing test/type error or writing a test, to guarantee the fix is real and not a cheat. Defines what counts as fake-green and how to verify a fix is legitimate.
Scanned 8/31/2026
Install to Claude Code
npx -y skills add localplugins/plugins --skill anti-fake-green --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Anti Fake Green?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/localplugins-anti-fake-green)More formats (shields.io, HTML) on the badges page.
---
name: anti-fake-green
description: Use whenever fixing a failing test/type error or writing a test, to guarantee the fix is real and not a cheat. Defines what counts as fake-green and how to verify a fix is legitimate.
---
# Anti-Fake-Green
Green must mean the code is actually correct. Making red go green by cheating is worse than leaving it red, because it hides the bug. These rules are non-negotiable.
## Use when
- Fixing a failing test or a type/compile error (as `fixer`).
- Writing or updating a test (as `test-writer`).
- Judging whether a change is a real fix or a cheat (as `green-guardian`).
## The one rule
Change the smallest amount of **production** code (or a genuinely-wrong test) needed to make the check pass **for the right reason** — never suppress the signal.
## Fake-green, at a glance
Reject any change that does one of these instead of fixing the cause:
- **Removes the test** — skip / delete / comment out / `.skip` / `.only` / `xit` / `xdescribe` / `@pytest.mark.skip`.
- **Weakens the assertion** — loosen an expected value, `toEqual` → `toBeTruthy`, delete assertions.
- **Silences the error** — `@ts-ignore`, `eslint-disable`, `# type: ignore`, empty `catch {}`, `except: pass`.
- **Widens the type** — to `any` / `unknown` / `object` just to clear a type error.
- **Pads coverage** — tests that assert nothing or only that a mock was called.
- **Bends the test to the bug** — editing the test to match buggy behavior when the *code* is wrong.
## Decision guide
1. Is production code wrong, or is the test wrong? Fix whichever is genuinely at fault; default to production code.
2. Would this change survive `green-guardian`'s diff inspection? If it matches any fake-green pattern above, it fails — redo it.
3. Can you prove it with revert-verification? If not, you haven't proven green.
4. Can't make it genuinely green? Stop and report exactly what's blocking. Never fake it.
## Deep references
- **`references/fake-green-patterns.md`** — side-by-side fake-green vs. real-fix examples in JS/TS, Python, Go, and Rust, plus the full rejection catalog `green-guardian` applies.
- **`references/revert-verification.md`** — the step-by-step procedure to prove a fix or a new test is real, using `git stash` / file checkout, with commands and pitfalls.
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!