GitHub - De-Cri/dont-kick-me-out: Copilot, not autopilot. A Claude skill that keeps you thinking while AI writes your code. · GitHub
/" data-turbo-transient="true" />
Skip to content
Search or jump to...
Search code, repositories, users, issues, pull requests...
-->
Search
Clear
Search syntax tips
Provide feedback
--><br>We read every piece of feedback, and take your input very seriously.
Include my email address so I can be contacted
Cancel
Submit feedback
Saved searches
Use saved searches to filter your results more quickly
-->
Name
Query
To see all available qualifiers, see our documentation.
Cancel
Create saved search
Sign in
/;ref_cta:Sign up;ref_loc:header logged out"}"<br>Sign up
Appearance settings
Resetting focus
You signed in with another tab or window. Reload to refresh your session.<br>You signed out in another tab or window. Reload to refresh your session.<br>You switched accounts on another tab or window. Reload to refresh your session.
Dismiss alert
{{ message }}
De-Cri
dont-kick-me-out
Public
Notifications<br>You must be signed in to change notification settings
Fork
Star
main
BranchesTags
Go to file
CodeOpen more actions menu
Folders and files<br>NameNameLast commit message<br>Last commit date<br>Latest commit
History<br>3 Commits<br>3 Commits
.claude-plugin
.claude-plugin
skills/dont-kick-me-out
skills/dont-kick-me-out
.gitignore
.gitignore
LICENSE
LICENSE
README.md
README.md
View all files
Repository files navigation
Don't kick me out!
Copilot, not autopilot. A Claude skill that keeps you thinking while AI writes your code.
The problem
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.
What it does
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.
The mechanisms
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
Before / after
Without the skill:
You: add rate limiting to /login<br>Claude: (wall of code) Done! Let me know if you need anything else.<br>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.<br>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?<br>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?
Does it actually work?
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.
A prediction I got 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?<br>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.<br>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...