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:youpredict 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 skilldetectsfading 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,yousummarize 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 movemake_chart
into the class, the instinct is to callself._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 handingdata
to a module, now we hand it to an object, soself.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 namedrender_chart
in the module's namespace. That works today only becausemake_chart
resolves that global at call time. Going throughself._renderer.render(...)
never performs that lookup — the patch is sitting on a name nobody reads anymore.
Then a ten-line repro:
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
fromReleases - 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