Your Knowledge Base Has a Second Job You're Not Using

Nine days ago, on an evening walk, I had the author Mark Forsyth in my ears talking about rhetoric. He does this thing where he takes a figure—rhetoric’s word for a named, repeatable sentence shape—and hands you the recipe.

For instance, polyptoton uses the same word twice in different grammatical roles (e.g., haters gonna hate). Scesis onomaton, by contrast, drops the main verb, letting the noun stand on its own. “London.” That’s the entire first sentence of Bleak House.

I listened to all 75 minutes of his appearance on How I Write but didn’t take a single note (I was out, after all, away from a screen and wanting to keep it that way). What I took from it was how much depth there is in the craft. Three thousand years of people working out which shapes lodge in a reader’s head, and almost none of it has made it into the Claude skills I use daily.

I’ve built around 103 at this point, and a lot of them write or edit something—this newsletter, LinkedIn posts, marketing emails, blog drafts. And between them, they know maybe five of the figures Forsyth spent an hour on.

I didn’t have that thought on my walk; it took a few days. But when it landed, I realized it wasn’t really about rhetoric, or even writing for that matter: every skill I’ve built runs on what I knew the day I wrote it, and I’d never had a way to change that.

Most of us build a knowledge base so Claude knows what we know.

We feed it our readings, call transcripts, decisions we’ve already made, and it stops answering as though we’ve never thought about anything. That’s most of what gets written about Second Brains, and most of what I’ve written about them, too.

But it has a second job, and it doesn’t depend on you remembering anything.

Everything you’ve built on top of Claude is a snapshot in time. Whether your setup calls them skills, projects, or custom instructions, it doesn’t matter whether you wrote it in March or last Tuesday—the moment you finished it, it stopped learning.

A skill records two things: what you knew about the work and how well you could explain it to the model. You’ve got better at both since you wrote it (I hope), but the file hasn’t moved.

And the explaining is where you’ve moved fastest.

Those gaps are what a knowledge base is actually for, provided you treat it as something you add to rather than something you keep. It’s where a model goes to learn, and it closes both from different directions.

• The knowledge gap closes because the new material is already in there. Claude can rebuild the skill against what you know now, rather than what you could remember the day you wrote it.

• The explaining gap closes because you’re no longer the one explaining. Claude reads the wiki and writes the update itself, so the skill gets a better model than the one you built it with, without you having got any better at asking.

But it only works if adding to the base costs nothing. If saving an episode were a job I had to remember to do, I’d have stopped in March. So I built a skill that takes the whole thing down to pasting a link.

Whenever I want to save an episode, I give Claude the YouTube link and ask it to save it to my knowledge base, which triggers the skill.

Claude can’t reach a YouTube transcript from a link, so I asked it to write a Python script that collects the caption track directly. The skill reads what comes back and writes it up as a markdown file, complete with a summary, the key insights, the quotes worth keeping, the full transcript, and wiki links out to related pages.

This episode came back as roughly 40,000 characters, and the script appended it to the bottom of the file rather than having Claude retype a word of it.

That file doesn’t sit in a folder waiting for me to remember it exists. It goes into a wiki I run in Obsidian (an idea I took from Andrej Karpathy), where anything worth its own page gets one.

So the episode didn’t arrive as a single markdown file. It arrived as nine, because Claude wrote eight new pages too, one per figure, and wired them into what was already there.

I didn’t file any of them, and I haven’t opened most of them since. How the wiki works is its own issue, but what matters here is that the figures Forsyth spent an hour on are now somewhere a skill can read them.

I wrote about this here, and it's worth restating, because it's the one doing the work here. Read a book, or listen to an episode, for its own sake and you come away with a vague sense of being better informed. Point it at a skill you already run, though, and you come away with a list of exactly what to fix.

So I pointed Claude at one of my editing skills, along with those eight new pages, and it weighed all eight, kept five, and turned three down, using rules I'd written into that file months ago and forgotten. One of the three was a technique for describing smells, and there aren't any in a piece about skill drift.

I went in wanting to give a skill something it didn’t have, and Claude returned an argument instead. And that’s the part I’d underestimated. Every skill you’ve built is still running on what you knew the day you finished it, and on how well you could say it then, and a knowledge base is the route back in.

But the skill isn’t an empty box waiting to be topped up. It has a position, and anything new has to get past it. You have your own version of this sitting on your computer, whether that’s a handful of skills, a few projects, or custom instructions you wrote once and haven’t opened since.

A podcast is what I happened to have that week. It could be a sales call, a customer interview, a competitor teardown, or a book you finished on holiday. The material changes; the route doesn’t.

Nine days ago I was out walking, and a man I’d never met named a technique I’d been using without knowing it. I didn’t write a word down. Below is the skill I’ve been running throughout this issue. Give it to Claude and ask it to install it for you.

You’ve been reading the result all the way down this page.