Your AI Skills Are Trapped | Here's How to Own Them

A lot of us have an AI agent with a brain now. It still probably doesn't know how to work as well as it should. So, a few weeks ago, I made a video called Open Brain. The argument was simple. Agents are becoming real, and if they're going to do useful work for you, they need access to your context in a way that works for you. They need to know what you're working on. They need to know what you decided last week. They need to know who the important people are. They need to know what you already tried. and they need memory that's not trapped inside one app, one SAS product, one model provider, one brain for every AI. And that video struck a chord because it named a bottleneck that we were all feeling, right? Every serious AI workflow still started with the same miserable ritual. Let me reexplain my life to this machine again. But there is a second problem that shows up as soon as you solve the memory problem. And I've seen it enough that I want to talk about it here and talk about how I'm solving it. Even if the agent knows what you know, it may still not know how you work. It may know the project. It may know the people. It may know the decision history thanks to open brain. And then you still have to explain the procedure from scratch. And you still have to say when you research this, don't trust stale model memory. You still have to say when you write for me, don't sound like a generic AI newsletter. You still have to say when you test this page, actually open the browser and check mobile and capture evidence and don't just tell me it looks good. You still have to say when you publish something, verify the live result. All of these things you have to reexlain and that is not a memory problem. You can have a perfect open brain setup and it still works that way. It's a procedure problem. And people using agents seriously are starting to feel it as a procedural debt. And you can see this in at least four different places across serious workers workflows. First in prompt bloat. People keep stuffing more rules into giant system prompts or markdown files and then wondering why the agent gets worse. And it's because every preference and edge case and repo note and safety reminder and formatting and structure fights the others for attention. At some point that stops being clarity and it just adds weight. Second, the reexlanation tax. Every new chat, every fresh agent session, every switch from cursor to claude code to codeex means you have to explain your voice and your testing standard and your project patterns and your safe commands and your definition of done all over again. That's not work. That's setup work pretending to be work. Third, instruction fragmentation. You end up with one set of rules in one tool, another set in another tool, repo specific nodes somewhere else, and custom instructions that slowly drift away from each other. Fourth, weak verification turns automation into a pile of review debt for you and me because the agent will say done, but the source is stale and the link is broken and the mobile view is bad or the change was never tested. So, the human still has to inspect so much. The agent didn't remove the work in some cases, it just moved the work into the review stage. This is the problem space open skills is built for and I'm launching it today. It's not that prompts are annoying. It's that agent work is developing procedural debt at exactly the moment agents are becoming capable of persistent action. Take a small product team at a startup that ships with both cursor and claude code on the same codebase. Let's say they spent weeks tuning a solid set of cursor rules, security boundaries, window to write tests, get workflow expectations, how to handle large refactors in the project's architectural patterns, and it worked really well inside cursor. Then they started using clawed code for bigger multifile changes and the rules didn't travel very cleanly. So one engineer ended up maintaining two versions of the same guidance. One in cursor rules and another in a claw.markdown file. Over time those files tended to drift. One got updated with a new testing rule after a painful incident. The other still said the old thing. And then a contractor joined the project and got handed a long onboarding prompt that tried to summarize both files. and it sounded comprehensive, but it was vague on the details that actually prevented bad deaths. The team is not short on intelligence in this situation, and they're not short on context. They're short on a portable way to carry the procedure itself. That is the gap Open Skills is designed to close. It's a gap in a multimodel world. That's what this video is about. It's not a prompt trick. It's not a list of clever AI hacks. It's not another folder of reusable wording. Open Skills is a public library of reusable agent procedures. The current version has 31 skills in seven categories and seven runbooks. Each skill comes with a copype setup prompt and the pattern is designed to work across codecs, claude code, and any other agent harness that can load a skill.mmarkdown style convention. And I want to be precise about differentiation here because this is not happening in a vacuum. A lot of the agent world is moving toward modular instructions. Individual tools have their own rule systems. Coding agents have their own markdown files. People are sharing tool specific skills and cursor rules and agent instructions. and those SIG scripts that keep those files from drifting. That is all the right direction. But open skills is making a more specific bet. The differentiated piece here is not skills exist. You can find skills. The differentiated piece is portable procedures as an operating layer. One markdown source of truth, narrow skills as primitives, run books as compositions, and verification as part of the contract, personal scope when the procedure belongs to you, and project scope when the procedure belongs to the repo. and a flywheel that turns repeated work into reusable skill candidates instead of letting the pattern disappear into old chat history. So if open skills becomes just another list of useful prompts, I failed. It blends into everything else. That's not what this is. But if it stays focused on portability and composition and verification and scope and compounding, it's a different layer. It's a needed layer. So what is a skill? Right? A skill is usually a small folder with a skill.mmarkdown file inside it. That's the simple version. The file tells the agent when to use the skill, when not to use the skill, what job the skill owns, what tools or files it should use, what boundaries apply, what output should look like, and how to verify the results. That's the unit, not a clever paragraph, not a vibe, not a one time chat, not a prompt. A reusable procedure an agent can load when the situation calls for it. A prompt is something you say once. And a skill is something your agent knows how to do from now on. If I give an agent a prompt that says, "Fact check this article," that's a request. If I give an agent a current information search skill, that's a procedure. It can say use live search when the claim is recent, when pricing might have changed and a software version matters or when training data might be stale. It can say compare sources and show the data. Separate consumed facts from inferred. recent, when pricing might have changed, when the software version matters, or when training data might be stale. It can say compare sources and show the date and separate confirmed facts from inference and let uncertainty block publishing if needed. Same thing with voice. If I say write this in my voice, the model has to guess. If I have a personal voice skill, it can tell the agent which real samples to read, which phrases to avoid, how long the sentences are, what argument structure works, and what fake AI language ought to be stripped out. Same thing with testing. If I say test the page, the agent may tell me it looks fine. If I have a browser QA skill, it can say open the actual route. Check the console. Check mobile. Verify the changed workflow. Capture screenshots and report the evidence. The procedure is the valuable part. That's the thing to take away from these three. The words are not enough. This is the same structural mismatch I talked about in the open brain video, but one level higher. OpenBrain said most secondbrain tools were built for human readers. That was true. They were useful, but they were not designed as agent readable memory infrastructure. Open Skills says most SOPs and prompts and checklists and docs and preferences have the same problem. They may be readable by a person, but they're not packaged as agent operable procedures. They don't have trigger rules. They don't say when not to run. They don't identify required tools. They don't define the output. They don't define the verification. And they don't travel cleanly from one agent harness to another. This is why the current world feels so painfully repetitive, so copy and paste. You have five AI tools and five separate piles of procedural sticky notes. One tool knows a little about how you write, another has a project instruction, another has repo rules, another has a custom instruction box, and another one has a chat history where you explained everything perfectly and you can never find it again. That is not a working system. That is just procedural sprawl. The answer is not a giant magical instruction block that says, "Be my perfect employee." That doesn't work. It's too broad. It's too vague. It can't be tested. It just isn't practical. The better path, the practical path is a library of small inspectable procedures that can be called from anywhere when needed. That's the answer to prompt bloat. Don't put every rule in the agents head all the time. Give it a clean way to load the right procedure when the work falls for it. And once you have skills that are transferable, the next step is runbooks. Skills are primitives. Runbooks are composition. Both are part of open skills. A skill answers, what can this agent do? A runbook answers, what can the system reliably produce? Take the creator workflow. A voice memo becomes a published page. That sounds like one task, but it's really a chain. Media transcription turns the audio into a transcript. Brain dump processing separates the real ideas from the rambling. Personal voice turns the best idea into a draft that sounds like the person. HTML artifact builder turns the draft into a usable page. Personal site publisher ships it with the right route and the right metadata and the link preview and verification. That is a runbook. Or take release day. Something important ships and you want to publish a useful accurate briefing while the facts still matter. Current information search gathers the facts. New release briefing turns those facts into a publishable package. Image prompting and generation create the visual. site publisher ships the page and stakeholder update closes the loop when something is actually live. That is speed with a quality bar. The point is not that one giant agent or giant skill knows everything. The point is that each skill owns a piece and those skills are Lego blocks and they're composable. So in that world, the transcription skill doesn't need to know how to publish, right? The voice skill doesn't need to know how to test a browser. The publisher doesn't need to know how to generate visuals. Each skill owns a specific contract. The runbook owns the flow. That's how real work gets done. And this is where the word open matters a lot. Open does not mean every skill is public by default. Open doesn't mean you paste secrets into a shared file. Open doesn't even mean every agent should be able to do everything. The skill becomes the source of truth. Cursor rules and clawed files and codeex instructions or whatever comes next can read from it or be generated from it instead of becoming separate drifting copies. Some procedures are personal. My voice is personal. My publishing habits are personal. My standards for a stakeholder update are personal. Other procedures are project local. The way you test a specific app should live with that app. The safe commands for one repo should not become universal rules for every repo. The known selectors and seed data and cleanup steps and deployment quirks should live where the project lives. That is another reason skills are not just prompts. They can be placed in the right scope, global when the procedure belongs to you, local when the procedure belongs to the project, and that is how you keep the system clean instead of turning into a giant pile of preferences that are a mixture of yours and the teams. The other big thing skills give you is verification. This is where the agent conversation needs to get much more serious. As long as AI was mostly writing text, a lot of people tolerated vague confidence. Just being honest here. But with agents, vague confidence is not enough. If the agent edited code, what test passed? If I built a page, what browser did it open? If it published something, what URL did it check? If it summarized a source, what source did it actually read? If it used current facts, what date did it verify? A good skill can define that proof ahead of time. It can say, "Do not call this done unless this evidence exists." That one sentence changes a lot because agents are very good at producing plausible completion language, and they're less reliable when the definition of done is vague. So, don't make it a vibe. put it in the skill. That's how you turn automation from review debt into leverage. And there's one more piece that matters, the flywheel. One skill in the library I'm launching today is called sessiontoskll extractor. The idea is simple, but it's very powerful. At the end of a substantial agent session, ask, did we learn a recurring non-obvious procedure worth preserving? Most of the time, the answer should be no. And that's part of the quality bar. You don't want to turn every little preference into a skill. But sometimes the answer is yes. Sometimes you discover a testing pattern or or a publishing checklist or a way to process transcripts or a repeatable source gathering process. And when that happens, the procedure should not disappear with that chat into the compost pile. It should become a skill candidate. That is the same compounding logic as open brain, but applied to procedures that help you work. Open brain compounds because every thought you capture makes future retrieval better. That's how it works. Open skills compounds because every good procedure you preserve makes future work more reliable. And that's where the leverage is now. And the real power is when the two systems come together. Open brain gives the agent the context, the project, the audience, the decisions, the prior work, the constraints. Open skills gives the agent the procedure, how to research, how to write, how to build, how to test, how to publish, and how to report what changed in a multimodel world where you can't be sure what model's going to be best next. And look at how this changes things for us. Right now, we humans are not spending the whole session saying, "Here's the background. Here's how I like this done. We humans can do the real work." And that gap, the ability to focus on real work, that compounds every week with open skills. It compounds every time a new model shifts. And you don't have to switch and cost yourself so much time. It compounds every time you try a new agent tool and you can bring open skills over because you are less locked into the memory and workflow assumptions of any one vendor. They don't deserve to have that. You do. You can move your context. You can move your procedures. You can plug better tools into the same operating layer. That is what open is supposed to mean here. Not vague openness, practical portability, your thoughts, every AI free for you to use your workflows, every agent. That is the call back to open brain here. It's the same spirit. And that's why open skills is not a prompt library. A prompt library is way too small for this problem. It just doesn't work in 2026 in the same way. Open Skills is more like a public operating manual for agent work. The value of Open Skills is not really in the 31 markdown files, although they're really good. The value is that every single file has a job, a scope, a trigger, a boundary, and a proof standard. That's what separates open skills from the broader wave of skills and rules. We need to have and we deserve to have skills that are transferable with clear runbooks associated because this is bigger than skills. You can build with these skills once and you can recombine them forever in any AI you want. That is the heart of what open skills is about. Skills don't make Asians perfect. Runbooks still require human judgment. AI skills are not magical autonomy people. But the real promise of open skills is still incredibly powerful because open skills means you don't have to explain the same procedure forever. It means you don't have to keep your working style in your head. You don't have to accept that every agent tool has its own separate pile of instructions. You can write the procedure down in a way an agent can load. That's open skills. You can inspect it. You can improve it. You can put it in the right scope and you can compose it into larger workflows and you can carry it forward as the tools change. That matters. So the decision rule is simple. If you do something with an agent once, a prompt is fine. If you are comfortable living in a world where you have to reacquire skills all the time and manually remember to set up loops to add to your skills as you go and then you have skill drift as you have codecs and cloud code and cursor in the mix, great. More power to you. If you want a solution that you can control, that's open skills. And that's what I'm launching today. If you want more information, you can check out the URL I'm showing right on the screen right now. you'll get all set up to go from there. I can't wait to see you there. Open brain has been just an incredible opportunity for the community to collaborate around building a memory system that is ours to control, not some SAS companies. I want open skills to be the same thing. It's a chance for all of us to contribute to a building set of skills that help us to be in charge of our work even as tools evolve and change. So we can stay flexible, so we can grow, so our skills come with us. You know, a few weeks ago I shared the reflection that one of the big challenges of the AI era is how a skilled knowledge worker moves from job to job and what they do with their skills that they acquire with AI along the way. Open skills is that answer. Bring your open skills to work and then take them with you when you go. Open skills help you be more effective across any AI tool that your work is going to throw at you and across your personal tools as well. If you're a company, open skills is a way for you and your teams to be more productive because we anticipate the team level. That's an important part of how we build meaningful things in the AIH. I do not believe the future is just a oneperson billion-dollar company. As much as that's fun, there will be some of them. I think a lot of the future is humans building cool things together and open skills is a powerful way to do that as well. So check out Open Skills. I'm so excited for it. I think it solves one of the most persistent and painful issues I've seen in the skills ecosystem. It should not be hard to move your skills between different AIs. It should not be hard to evolve your skills over time and it should not be hard to compose your skills into runbooks. Open Skill Solves for all of that. Check it out. Have fun with it and contribute to the build. Let's make it great together. Cheers.