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

1 The Memory Problem Isn't Enough

▶ 0:00

Nate's previous video, Open Brain, tackled the memory problem — agents need access to your context (what you're working on, decisions from last week, important people, what you've already tried) in a way that isn't trapped inside one app, one SaaS product, or one model provider.

Open Brain struck a chord because it named a universal bottleneck: every AI workflow still started with "let me re-explain my life to this machine again."

But solving memory reveals a second problem: even if the agent knows what you know, it may still not know how you work. It may know the project, the people, the decision history — and you still have to explain:

• "When you research this, don't trust stale model memory"
• "When you write for me, don't sound like a generic AI newsletter"
• "When you test this page, actually open the browser, check mobile, and capture evidence"
• "When you publish something, verify the live result"

2 Four Types of Procedural Debt

▶ 1:39

Nate identifies four places procedural debt shows up in serious AI workflows:

1. Prompt bloat — stuffing more rules into giant system prompts or markdown files until every preference, edge case, repo note, safety reminder, and formatting rule fights the others for attention. At some point, clarity becomes dead weight
2. Re-explanation tax — every new chat, every fresh agent session, every switch from Cursor to Claude Code to Codex means re-explaining your voice, testing standards, project patterns, safe commands, and definition of done. "That's not work. That's setup work pretending to be work"
3. Instruction fragmentation — one set of rules in Cursor, another in Claude Code, repo-specific notes somewhere else, custom instructions drifting apart over time
4. Weak verification — the agent says "done" but the source is stale, the link is broken, the mobile view is bad, or the change was never tested. "The agent didn't remove the work — it just moved it into the review stage"

3 What Open Skills Is

▶ 2:51

Open Skills is a public library of reusable agent procedures, launching today. The current version includes 31 skills in 7 categories and 7 runbooks. Each skill comes with a copy-paste setup prompt designed to work across Codex, Claude Code, and any agent harness that supports a SKILL.md-style convention.

What Makes It Different

The differentiated bet is not "skills exist" — the space is already moving toward modular instructions with cursor rules, markdown files, and agent-specific skill scripts. The bet is portable procedures as an operating layer:

• One markdown source of truth — not separate drifting copies per tool
• Narrow skills as primitives — each skill owns one specific job
• Runbooks as compositions — chain skills into workflows
• Verification as part of the contract — proof standards built in
• Personal scope + project scope — skills go where they belong
• A flywheel — repeated work becomes skill candidates, not lost chat history

4 When Cursor and Claude Code Rules Don't Travel

▶ 3:04

Nate gives a concrete example: a small startup product team using both Cursor and Claude Code on the same codebase.

• They spent weeks tuning Cursor rules — security boundaries, test workflows, architectural patterns — and it worked great inside Cursor
• Then they started using Claude Code for bigger multi-file changes, and the rules didn't travel cleanly
• One engineer ended up maintaining two versions of the same guidance — one in .cursorrules, another in CLAUDE.md
• Over time, the files drifted — one got a new testing rule after a painful incident, the other still had the old version
• A contractor joined, received a long onboarding prompt summarizing both files — comprehensive-sounding but vague on the details that actually prevented bad deploys

The team isn't short on intelligence or context. They're short on a portable way to carry the procedure itself. That's the gap Open Skills is designed to close.

5 Prompt vs. Skill — Three Concrete Examples

▶ 5:36

A skill is a small folder with a SKILL.md file that tells the agent: when to use it, when not to use it, what job it owns, what tools/files it needs, what boundaries apply, what output should look like, and how to verify results.

Example 1: Current Information Search

• Prompt: "Fact check this article" — a one-time request
• Skill: Use live search when claims are recent, when pricing might have changed, when software versions matter, or when training data might be stale. Compare sources and show dates. Separate confirmed facts from inference. Let uncertainty block publishing if needed

Example 2: Personal Voice

• Prompt: "Write this in my voice" — the model has to guess
• Skill: Read specific real samples, avoid these phrases, use this sentence length, follow this argument structure, strip out fake AI language

Example 3: Browser QA

• Prompt: "Test the page" — the agent may say "it looks fine"
• Skill: Open the actual route, check the console, check mobile, verify the changed workflow, capture screenshots, report the evidence

The procedure is the valuable part. The words alone are not enough.

6 Skills as Primitives, Runbooks as Composition

▶ 8:46

A skill answers: "What can this agent do?" A runbook answers: "What can the system reliably produce?"

Runbook Example 1: Creator Workflow

Voice memo → published page. Sounds like one task, but it's a chain of skills:

1. Media Transcription → audio to transcript
2. Brain Dump Processing → separate real ideas from rambling
3. Personal Voice → draft that sounds like the person
4. HTML Artifact Builder → draft to usable page
5. Personal Site Publisher → ship with correct route, metadata, link preview + verification

Runbook Example 2: Release Day

Something ships and you need an accurate briefing while facts still matter:

1. Current Information Search → gather facts
2. New Release Briefing → facts to publishable package
3. Image Prompting & Generation → create the visual
4. Site Publisher → ship the page
5. Stakeholder Update → close the loop when something is live

The transcription skill doesn't need to know how to publish. 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. Skills are Lego blocks — composable.

7 Scope — Personal vs. Project

▶ 10:18

"Open" doesn't mean every skill is public by default or that you paste secrets into a shared file. It means the skill becomes the source of truth — Cursor rules, Claude files, and Codex instructions can read from it or be generated from it, instead of becoming separate drifting copies.

• Personal scope — your voice, publishing habits, and stakeholder update standards are personal. They travel with you across every project and every tool
• Project scope — testing patterns for a specific app, safe commands for one repo, known selectors, seed data, cleanup steps, and deployment quirks should live where the project lives

This 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 it belongs to the project. That's how you keep the system clean instead of accumulating a giant pile of mixed personal and team preferences.

8 Verification — Don't Call It Done Without Proof

▶ 11:09

As long as AI was mostly writing text, people tolerated vague confidence. But with agents taking action, vague confidence isn't enough:

• If the agent edited code — what test passed?
• If it 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?

Agents are very good at producing plausible completion language. They're less reliable when the definition of done is vague. Put it in the skill — that's how you turn automation from review debt into leverage.

9 The Flywheel — Turning Sessions into Reusable Skills

▶ 11:58

One of the skills in the Open Skills library is the Session-to-Skill Extractor. At the end of a substantial agent session, it asks: "Did we learn a recurring, non-obvious procedure worth preserving?"

• Most of the time, the answer should be no — that's part of the quality bar. Not every preference should become a skill
• But sometimes you discover a testing pattern, a publishing checklist, a transcript processing method, or a repeatable source-gathering process
• When that happens, the procedure should not disappear into old chat history. It should become a skill candidate

This is the same compounding logic as Open Brain, applied to procedures. Open Brain compounds because every captured thought improves future retrieval. Open Skills compounds because every preserved procedure makes future work more reliable.

10 Open Brain + Open Skills Together

▶ 12:53

The real power emerges when both systems work together:

• Open Brain gives the agent the context — the project, the audience, the decisions, prior work, constraints
• Open Skills gives the agent the procedure — how to research, how to write, how to build, how to test, how to publish, how to report what changed

In a multi-model world where you can't be sure which model will be best next, this combination means:

• You're not spending sessions on "here's the background, here's how I like this done"
• The gap compounds every week — every time a new model ships, every time you try a new agent tool
• You're less locked into the memory and workflow assumptions of any one vendor

11 The Decision Rule & the Launch

▶ 15:27

Nate offers a simple decision rule:

• If you do something with an agent once → a prompt is fine
• If you do it repeatedly and you're comfortable re-explaining, re-acquiring skills, managing drift across Codex/Claude Code/Cursor → that's a choice
• If you want a solution you can control → that's Open Skills

The Vision

Open Skills is not just for individuals. At the team level, it's a way to make teams more productive — shared procedures that compound across the group. Nate explicitly pushes back on the "one-person billion-dollar company" narrative: "A lot of the future is humans building cool things together, and Open Skills is a powerful way to do that."

Skills should be portable across any AI tool your work throws at you. They should evolve over time. They should compose into runbooks. Open Skills solves for all three.

🎯 Key Takeaways

🔗 Resources & Links

• The Complete Open Skills Guide — full written post with setup instructions

⏱ Timestamp Index