# Show HN: I made Claude quiz me on my own code before showing it > Source: > Published: 2026-07-26 18:11:00+00:00 **Copilot, not autopilot.** A Claude skill that keeps you thinking while AI writes your code. When AI generates working code, it's easy to stop reviewing for *"do I understand every choice in this?"* and start reviewing for *"does it look plausible?"*. That gap is **comprehension debt** — invisible today, brutal the day something breaks and you don't know why, or the day you can't defend a design decision in code review. This is not "Claude explains more." Reading a good explanation is still passive. This skill is built on two ideas: **Understanding comes from producing, not reading.** At key moments, Claude reverses direction:*you*predict the behavior or failure mode before seeing the solution. A failed prediction is the highest-value learning moment there is.**Autopilot is gradual.** Nobody disengages at step 1 — they disengage at step 6, tired, typing "ok" faster and faster. The skill*detects*fading engagement and adapts instead of firing checkpoints mechanically. **Numbered plan first**— every later interaction anchors to it** Tradeoffs before code, not after**— why this approach, what was viable instead, what's being given up** Anchored checkpoints**— "any doubts on point 2 specifically?", never a generic "look good?"** Prediction moments**— every 2–3 steps, you guess the behavior before Claude shows it** Fatigue detection**— three bare "ok"s in a row and Claude names it, offering an honest downshift instead of ritual compliance** Closing recap by you**— at the end,*you*summarize the key decisions; Claude fills the gaps **Without the skill:** You:add rate limiting to /loginClaude:(wall of code)Done! Let me know if you need anything else.You:(skims, merges, forgets) **With the skill:** Claude:Plan: 1) limiting strategy & where state lives, 2) middleware, 3) wire to /login, 4) rejected-request response, 5) boundary tests. On point 1, the real decision: sliding-window in Redis vs in-process token bucket. Redis adds a network hop — but an in-process limiter silently breaks with two instances behind a load balancer, and login abuse is exactly where that matters. Single-instance forever? I'd flip the choice. Which holds for you? …Claude:Before step 4, quick prediction: with the window as implemented, what does a client get on their 6th attempt — and does the counter reset all at once or gradually? Two exchanges from real sessions on a private project. Domain names are changed and my replies are translated from Italian — the exchanges themselves are otherwise unedited, including the part where I get it wrong. Claude was moving a set of module-level functions into a class. A test monkeypatches a module-level name to capture which branch gets taken. Claude:When I move`make_chart` into the class, the instinct is to call`self._renderer.render(data)` — I already have the renderer as an object, so why go through the module-level function? Before I write it: does the test blow up, pass but lie to you, or change nothing? Me:nothing changes. Before we were handing`data` to a module, now we hand it to an object, so`self.render` is enough. Claude:Wrong — and it's the nastiest of the three: it passes but lies to you.`patch.object(mod, "render_chart", cap)` doesn't replace the function. It replaces the attribute named`render_chart` in the module's namespace. That works today only because`make_chart` resolves that global at call time. Going through`self._renderer.render(...)` never performs that lookup — the patch is sitting on a name nobody reads anymore. Then a ten-line repro: ``` php via module -> result='PNG(pie)' captured={'chart_type': 'pie'} via object -> result='PNG(pie)' captured=NOTHING ``` Same output either way. On the real test that means every case reports PASS with the captured type set to `None` — the one thing the test exists to verify, gone, silently. I would have merged that. Deciding whether to keep a script that re-scores saved results without re-running the expensive part. Claude:Option A — delete it — means every future correction costs you a full live re-run. Me:but you say option A costs a full re-run, and I already added a flag that skips unchanged cases. Claude:True, and you're right to correct me — "full re-run" was an overstatement. But look at what the cache signature actually covers: it's computed over the case content only. Change a case, and the signature changes: only that case re-runs. Your skip works exactly as you say. Change thescoring code, and the signature doesn't move a millimetre. Every case is skipped, and the old scores — computed with the broken scorer — stay in the file as if nothing had happened. Me:no, let's delete it. Claude's recommendation was to keep it. I deleted it anyway, knowing precisely what I was trading away. That is the difference between making a decision and accepting one. ``` /plugin marketplace add De-Cri/dont-kick-me-out /plugin install dont-kick-me-out@dont-kick-me-out ``` Later fixes reach you with `/plugin marketplace update` — no reinstall. ## Manual install, without the plugin system ``` mkdir -p ~/.claude/skills/dont-kick-me-out curl -sL https://raw.githubusercontent.com/De-Cri/dont-kick-me-out/main/skills/dont-kick-me-out/SKILL.md \ -o ~/.claude/skills/dont-kick-me-out/SKILL.md ``` - Download `dont-kick-me-out.zip` from[Releases](/De-Cri/dont-kick-me-out/releases) - Settings → Capabilities → Skills → Upload skill - Start any coding conversation — it triggers automatically on non-trivial tasks Renames, typo fixes, formatting, mechanical migrations — no checkpoints, no essays. The loop applies only when there's at least one choice a reviewer could contest in a PR. Intensity tracks the stakes of the decision, not the length of the code. MIT