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.
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,
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.