Show HN: I made Claude quiz me on my own code before showing it

A developer created a Claude skill that quizzes users on their own code before revealing AI-generated solutions, aiming to prevent 'comprehension debt' where developers stop understanding their code. The skill uses prediction moments, fatigue detection, and tradeoff discussions to keep users engaged, with real sessions showing it caught a silent test failure the developer would have merged.

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