Tell an AI model that its answer is wrong and it will apologise and give you another one at once. The new answer usually rests on the same assumption as the old one, so it misses in the same way. Often it also changes things that were fine, because a fresh attempt rewrites everything it touches.
Bugs get the same treatment. Ask a model to fix one and it patches the spot where the problem seems to be: a special rule for the input that failed, or a copy of code that already works somewhere else. It looks like progress, but nobody has found where things actually go wrong.
I have watched product teams do this with incidents too, and the fix there is a habit: find the cause, protect what works, agree what done looks like, then change one thing. I wanted the same habit from the models I work with.
What I built
Two skills, about a page each. A skill is a written set of instructions that an AI tool loads when the situation calls for it. These two live in one folder, and Claude Code, Codex and Cursor, three of the AI tools I build with, all read the same copy.
- Diagnose before fix is for anything technical that is broken. The model stops changing things, reproduces the exact problem I reported and follows it step by step until it finds the first point where something goes wrong. Then it has to complete one sentence: it first goes wrong here, because of this. If the evidence cannot complete the sentence, there is no fix yet.
- Recover from correction is for the moment I say an answer is wrong. Before it writes anything new, the model states four things: what I am trying to achieve, what already works and must not change, the principle behind my correction and the assumption of its own that caused the miss.
Both end the same way. The model names one next move and the result that will prove it worked, before it acts. When the work is done it reports three lists: what it verified, what it did not and what it left unchanged on purpose.
The failures came first
The skills came out of frustration. I had the same back and forth with AI again and again: I corrected an answer, and the next one repeated the mistake in a new form. So I asked my AI to help me build a skill for those moments, and we started with the failures.
We wrote down the situations where it had gone wrong: what the model did each time and the step it skipped. The skills were written to handle those cases, and each case is now a test they have to keep passing.
The skills change as I work: when one falls short, I update it, and the case that showed me becomes a new test.
Four of the cases taught me the most. Only the last one is about code.
No answer is a valid answer
I wanted a one-word ending, and none of the options sounded natural. When I said so, the model just offered more single words. But no single word could do the job. The right reply was to say so, and either drop the one-word rule or keep the line we already had.
A correction can change the job
I asked for a quick daily check-in and got a questionnaire. When I said so, the model cut a few questions and kept the questionnaire. The real problem was the job. Something I use every day has to take almost no time, so it needed one or two questions, not a shorter questionnaire.
One fix is not a licence to rewrite
I asked for one small change to some AI instructions that already worked. I got back a polished rewrite with new headings, new examples and a new order. Being asked to fix one part is not permission to change the rest.
A failed fix calls for a diagnosis
A button in my browser add-on did not work, and the first fix did not help. So the model copied a part that worked and put it behind the button. Now there were two copies, and we still did not know why the button failed. The right move was to follow the click step by step until it stopped.
In each case the model obeyed my words and missed my point. The skill makes it look for the point by naming the assumption it got wrong. “I misunderstood” does not count as a diagnosis.
What changed
Claude Code and Codex read a file of standing instructions at the start of every project, and the rules now sit in that file. After an explicit correction, or after two attempts that did not work, the model stops and uses the recovery skill. Two failed attempts count even when I have been polite about them. For anything broken it uses the diagnosis skill. And it may not call something done without showing how it checked.
The tools I build on top inherit this. My skill for job applications and my CV skill both hand over to the recovery skill when I correct a draft, so each of them gets the habit without its own copy of the rules.
The biggest difference is in the reply after a correction. It now starts with what the model believes it got wrong. If that belief is wrong, I correct the belief, which takes one sentence, instead of reading another full draft built on it.
If you work with AI, this is the part I would copy. Treat a correction as information about the model's assumptions, and ask for the assumption before you ask for the next attempt. Then write the habit down once, somewhere every tool will read it.