Hostile self review

Skill fbsmna-coder/karpathy-pro-max/skills/hostile-self-review

Stop Claude Code from hallucinating — Karpathy-grade discipline in 8 skills

Install

npx -y skills add fbsmna-coder/karpathy-pro-max --skill hostile-self-review

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Review your own diff as a skeptic before declaring done. Use after implementing any non-trivial change to catch bugs, scope creep, hidden assumptions, and overclaims that you would otherwise ship.

The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

2.7 KB, as published. Nobody here has run it

Hostile Self-Review

The default failure mode after writing code is declaring it done. The agent has just spent N tool calls building it, is invested in the outcome, and pattern-matches "I wrote the code → task complete." This skill inserts a deliberate skeptical pass before that declaration.

When to apply

After any non-trivial change, before reporting completion. "Non-trivial" = anything beyond a typo, a one-line config change, or a comment edit.

How to apply

Read your own diff with this question in mind: "If a peer reviewer wanted to reject this PR, what would they correctly point at?"

Find at least 3 real concerns. If you cannot find 3, you did not look hard enough — re-read with these prompts:

The skeptic's checklist

Did I actually solve the stated problem, or a related one? Re-read the original request. Compare to what shipped. Are they the same?
What edge case did I not handle? Empty input. Maximum input. Concurrent calls. The unhappy path. Be specific — name the case.
What did I assume that I did not verify? "I assumed the API returns ISO timestamps" — did you check? "I assumed the column exists" — did you grep the schema?
What did I touch that wasn't in scope? Reformatting, renaming, adjacent edits. List them. Either revert or justify each.
Where did I claim something works without evidence? "Should now handle X correctly" — show the test, the curl, the screenshot. If you can't show it, you didn't verify it.
What would break if my change is wrong? Blast radius: just this function? The whole request path? Production data? User-facing behavior?

Output format

End your work with:

## Self-review

Concerns I found:
1. <concern> — <action: fixed / accepted with reason / left for user>
2. ...
3. ...

Verified: <list of concrete checks performed>
Not verified (and why): <list>

If the list is empty after honest review, write "Self-review found no concerns" — but only after going through the checklist.

Anti-pattern

Theatrical self-review: listing fake concerns to look thorough ("I should add more comments"). Real concerns are uncomfortable. If your self-review is comfortable, it isn't real.

Why this matters more than external review

External review happens after you've shipped. Self-review happens before. The cost of catching the bug is one minute of re-reading vs. one rollback + one fix + one redeploy.