Yesterday I wrote about fat skills and thin harness as theory. Today I had to use it on two real fires.
The rule held both times. Here's what happened.
Fire One: The Bots Showed Up
The grant application app I've been building had something interesting happen. Bots started crawling it. Real ones. The B2A theory I keep talking about — that AI agents are the new customers — started showing up in the logs.
That's the good news. The bad news is the logs were full of stuff the agents tried to do and couldn't, because the platform wasn't ready for them.
The wrong move would have been to babysit the logs every morning. The right move was to make the platform read its own logs, find the gaps, and improve overnight while I sleep. So that's what I set up. A daily task that pulls the feedback, prioritises the fixes, and ships the improvements.
Then I made a hard marketing push: get listed on every MCP registry that exists. More registries, more agents discover it, more feedback, more learning. The platform gets smarter the more agents use it.
Fat skill. Not just code. A repeating process that improves itself.
Fire Two: Google Wouldn't Index My Site
Then the bigger fire. TestVentures.net was getting rejected by Google. Crawled, but not indexed. I'd tried to fix it five times. Each time I thought I had it. Each time it came back broken.
The honest answer for why this kept happening: I'm not on WordPress. Not on Webflow. Not even on Ghost, which I love. I'm writing in Claude and deploying flat files to Cloudflare. Fast, but no SEO framework — no plugin telling me when a canonical tag is wrong, no platform catching the mistakes a CMS would catch automatically. I'm making this up as I go.
Five hours of digging, and I finally had it cleaned up. The kind of bug you only catch by reading the actual response Google gets, not the page you think you wrote.
But here's the move that mattered: I didn't just fix it.
I encoded the fix.
Now there's a deploy skill that runs a pre-flight check before anything ships, deploys it, then runs five hard checks against the live site to confirm it actually works. If any check fails, the script tells me what broke and how to fix it. The next time this exact problem tries to come back, it gets caught at the door.
Eating my own dog food, hmm, is that right? I finished the fixed and immediately put in a lock the process in the form of a new markdown rule, or a skill. Then tested it right then, made sure that the system was up to date and agreed upon it.
One other thing happened today that was interesting, I have another software dev collegue that came to me about a very interesting problem that he has a patent on. I hope to become one of his power users soon, but can't divulge anything about it because it's his deal and he isn't ready to let it out. All I can say is that it fits well into the things I'm working on now.
The Rule
Both fires taught the same lesson: the first time you solve something hard, it costs you a day. The second time should cost you nothing.
That's the actual point of fat skills. Not "write good prompts." It's every problem you solve once becomes a skill that solves itself the next time. The harness stays thin. The skills get fatter. The system improves with use. Now, I'm starting to sound like a broken record but it's fine, since I know that likely only 1 or 2 people will read this blog in the next 30 days. Crickets!!
What to do: when you fix something painful, stop. Don't move on. Spend the extra 30 minutes encoding the fix into a skill. You will pay yourself back the first time it would have hit you again.
Today's Cleaned-Up Daily Log
What ran:
The B2A grant app got its self-improvement loop wired up. It now reads its own usage logs every day, surfaces the patterns where agents got stuck, and queues the fixes. A separate task submitted the platform to seven different agent registries so more agents find it. Also codified the mcp registration process so the next time that isn't so painful. The reason I have time to work on so much personal stuff is because the fulfilment hasn't actually kicked while I am waiting for payments to come in. It's bad practice work on spec. I'll do it of course, but it also prompts for client payments to come in faster.
TestVentures.net's indexing problem got fully resolved. Root cause was a mismatch between the URL Google was reading and the URL I was telling Google to read. Both now match. The sitemap was re-submitted to Google. Indexing was requested on the four highest-priority pages.
A new deploy skill went into the system. From now on, every deploy runs a pre-flight check, pushes the changes, waits for propagation, and runs five live checks. If anything is wrong, I know within thirty seconds.
Two fires. Two skills. One rule.
Revenue: $0. Clients: 2. Prospects: 5.
Day 20 of 365.