Delete your old finance skills.
Not the one you built last week. The old ones. The skill you wrote in March, patched in April, then tightened again in June when a new model came out and the output changed under you. The one you have edited so many times you stopped counting.
I can hear the objection already, because it was mine. Why would I delete a skill I have been updating with every new model anyway? That file has survived three model generations. Every fix in it was paid for by a bad output on a real company. Delete it and start fresh, and some nuance in there is going to get missed.
Hold that objection. It is correct. It is also the reason most people never see the real problem.
Open one of your old skills right now and read it top to bottom. Count the rules you cannot explain. You know you wrote them. You cannot say what they were for. Right?
Every one of those rules went in on a specific day, to stop the model you had back then from doing something that annoyed you. Maybe it hedged when you wanted a verdict. Or it kept estimating numbers the filing never disclosed, so you wrote a line that said never estimate, only quote. The line worked. You moved on.
Then a better model came out and stopped doing the thing.
The line stayed.
Nothing removes it, because nothing ever does. A rule that quietly died and a rule that is holding your entire output together look identical from the outside. The only way to tell them apart is to pull one out and run the skill again, and nobody does that. I did not either.
So the file only grows. Ten edits, twenty edits, three or four models, six months of honest maintenance, and what you own at the end of it is a working skill buried under fixes for problems that no longer exist. A patch log.
Before you decide I am telling you to select a year of work and press delete, I am not. There is one step that makes the whole thing safe, and I learned why it matters the hard way, because before writing a word of this edition I sat down and read my own oldest skills, top to bottom, rule by rule, and what I found in them changed what this edition is about.
We will get there. First, the reason updating never fixes this on its own.
Alpha with AI is my full-time work. Paid subscribers get the Research Dives and the model portfolio, with the full research behind every entry. AI Prime is the home of the complete AI workflow library, every edition like this one, archive and new. If this work earns a place in your process, upgrade below.
Why updating an AI skill is not the same as rebuilding it
Think about how a rule actually gets into a skill file. Nothing about it is planned. The model gives you a bad output on a real company, on a real morning, and it costs you twenty minutes. You trace what went wrong, you write a line to stop it, you run it again, and the output comes back clean. The rule has earned its keep.
Now think about how a rule leaves the file.
It does not. There is no moment for it. A bad output triggers an edit, but nothing triggers a deletion, because a stale rule does not announce itself. It does not error. Nothing in the output points back at it. It just sits there, either doing nothing or quietly making the output worse, and from where you sit both look exactly like a rule that is working.
So the file moves in one direction. Every model release adds a few fixes and removes none, and the skill slowly fills up with corrections for the habits of models that are no longer running.
Fine, you say. Then I will have the model clean its own house. Hand it the file, tell it a new model just shipped, ask it to improve the skill.
I have done this many times. Here is what actually happens. The model works on what is in front of it. It tightens your wording, reorders your sections, patches the gap you pointed at, and hands back a file that is genuinely better than the one you gave it. What it will not do, not once in my experience, is tell you that half the structure exists to manage a model from March and the March model is gone. You did not ask that question, and the file sitting on the page keeps it from ever coming up.
That is the difference, and it took me longer to see than I want to admit. An update can only change so much. It polishes the answer to a question I asked months ago. Starting fresh is the only thing that goes back to the question itself.
I am not guessing at any of this.
By the time these skills reached everyone, I had already built mine, broken them, and rebuilt them for months. I walked through the full discipline of building one properly, including the four questions I answer before writing a single line of a skill file, in Learn to build a Claude skill for equity research. Start there if you have never built one, because everything in this edition assumes a skill worth saving.
The skills from those beta months have been through more updates than I can count.
Which brings me to this month, and to the person who finally pushed me to look at them properly.
What the creator of Claude Code says to do with your old skills
For the last couple of months, some of my oldest working skills had been coming back with weaker output than they used to. Not broken. Just not as good as a month ago, two months ago.
I blamed the model. Every time results come back worse than they did two weeks back, people blame the model. I was one of them. I even said it out loud on social media.
Then this month I ran into the creator of Claude Code saying the opposite. Boris Cherny, in a July interview at Y Combinator:
Every six months, delete your CLAUDE.md, delete your skills, delete your hooks. See what the model does.
And the part that pushed me harder than the advice. For Opus 5, his team deleted 80 percent of Claude Code’s own system prompt. His reason, in his words: a lot of it “was correcting for these behaviors that the model should have known, but it didn’t. Now Opus 5 just does it.” They do this on every release. A new model comes out, and they delete and rewrite a chunk of what they had.
That stopped me. The team closest to the model does not trust its own year-old instructions. I was trusting mine completely, and blaming the model for the results.
I will be honest here. I had a little bit of this idea myself, and I was not pushing it, because everything was working. Sometimes you need someone who deleted 80 percent of their own work to push you. I needed that push.
So I did what I asked you to do at the start of this piece. I opened my everyday skills, the ones that run my actual research, and read them top to bottom, rule by rule.
Here is the thing about any skill you actually use. The history is always there, sitting inside the file. No skill gives you the output you want on day one. It makes mistakes, you correct it, it makes new mistakes, you correct those, and update after update it adds up to the output you had in mind. That is true for every skill I run daily, and it will be true for every skill you build after reading this.
So the history was never the problem. I read those files and the history is all there, every fix I ever made. What is not there is a single reason. The file remembers what I changed. It does not remember why. Every rule I could not explain is a decision I made once, against a model that may not even be running anymore.
The reasons survived somewhere else, though. Somewhere I was not looking. That is where the rebuild starts.
A small note, and the only sponsor here is me. I keep getting messages asking how I set up Claude Code for stock research, beyond what the editions can teach. So I am opening a small consulting program: I set your system up with you, then support sessions over the following months as your real problems show up. I am doing a lot of other things, so seats are very few. If that is you, the waitlist is on the website or reply to this email.
Before you rebuild an old skill, find where its reasons were written down
Every rule in every skill was explained once. Not in the file. To a person.
Think about how a skill gets into anyone’s hands. Nobody installs a file of instructions on blind trust. Somebody had to convince you first. If you downloaded a skill from one of my editions, you read the piece before you installed it, and that piece walked you through why every rule was in there. If you built your own, you did the convincing somewhere else. The message where you explained it to a colleague. The note where you talked yourself into building it.
The reasons never make it into the file, because the file does not need convincing. You do. So the reasons sit wherever the convincing happened, and they are still sitting there today.
Let me show you what I mean with one of mine. And let me explain the skill properly first, like you have never read me before, because the example is useless if the skill does not make sense.
After a company announces its quarterly results, the numbers are public. Everyone has seen them. What nobody can see in the numbers is whether the people running the company believe in what comes next. So I watch what management does in the six weeks after the announcement. A team that just delivered a great quarter books itself everywhere. Conferences, investor events, analyst calls. They want to be in the room, because every question is now a question they can answer. A team that just delivered a bad quarter books nothing. Not because the numbers are secret. Because every room is now full of questions they do not want to answer. I am not predicting the next quarter with this. I am reading whether the insiders are behaving like things are fine or behaving like things are not, and that behaviour sits on public pages weeks before any analyst changes a number. I call this skill the calendar tell, and I taught the whole build in I Taught AI to Read a Company’s Earnings Before Wall Street Does. The Tell Is on Its Calendar.
Inside that skill sits one rule. Do not judge this quarter’s calendar on its own. Compare it against the same six weeks after each of the company’s last four or five results. If you opened the skill file today, that is all you would find. One line. Follow it or do not.
But when I published the skill, I had to convince you that line was right. So the full reasoning is on that page: some companies are simply busier than others, some have a heavy season and a quiet one, so counting events tells you nothing until you compare the company against its own normal.
That highlighted paragraph is what the file never held. The file has the rule. The page where the skill was first explained has the reason.
So here is the move, and it works whether you built your skill or downloaded it. Before you rebuild anything, go back to where the skill was first explained to a human being. For a skill you took from these pages, that is the edition it came from. For a skill you built yourself, it is your own note, your own message, wherever you once did the convincing. Collect that explanation. It is half of the skill, and it is the half the file cannot give you.
But an explanation is not a skill file. I cannot install an article. To turn the explanation back into a working skill, you need to know what you are looking at inside the old file, because not everything in there deserves to survive. Four kinds of things live in every skill file, and they age at completely different speeds.
That sort comes next.
If this edition has earned its read so far, tap the ❤️ at the top of this email or page. One tap from you is how Substack decides whether this piece reaches anyone beyond my own subscribers.