Jonathon's AI Wiki

Open Skills — Portable Agent Procedures (Nate B Jones)

6 min read

Source: raw/Your_AI_Skills_Are_Trapped_Here_s_How_to_Own_Them.md (YouTube, creator: Nate B Jones, “AI News & Strategy Daily”)

Open Skills is a public library of reusable, portable agent procedures launched by Nate B Jones — the companion layer to his earlier Open Brain (portable agent memory). Where Open Brain answers “does the agent know what I know?”, Open Skills answers “does the agent know how I work?” The launch version ships skills across seven categories plus runbooks, each as a skill.md-style file designed to load across Claude Code, Codex, Cursor, and any harness that reads the convention. The core bet: as agents become capable of persistent action, the bottleneck shifts from memory to procedural debt — and the fix is portable, composable, verifiable procedures rather than ever-bigger system prompts.

Key Takeaways

  • The problem is procedural debt, not prompt-craft. Even with perfect memory, you still re-explain how to research, write, test, and publish every new session. Jones names four symptoms: prompt bloat (rules fighting for attention in giant system prompts), the re-explanation tax (re-teaching voice/standards on every tool switch), instruction fragmentation (drifting copies across Cursor rules, claude.md, repo notes), and weak verification (the agent says “done” but the work moved into your review queue).
  • A skill is a procedure, not a prompt. A prompt is something you say once; a skill is something the agent knows how to do from now on. The unit is a small folder with a skill.md that declares: when to use it, when NOT to use it, the job it owns, required tools/files, boundaries, output spec, and how to verify the result.
  • Skills are primitives; runbooks are compositions. A skill answers “what can this agent do?”; a runbook answers “what can the system reliably produce?” Example runbook (creator workflow): voice memo to transcription to brain-dump processing to personal-voice draft to HTML artifact to site publisher. Each skill owns one contract; the runbook owns the flow (Lego blocks).
  • Verification is part of the contract. A good skill defines proof ahead of time: “do not call this done unless this evidence exists” (which test passed, which URL was checked, which source was actually read, which date was verified). This converts agent output from review-debt back into leverage, because agents reliably produce plausible “completion language” when the definition of done is vague.
  • Scope is explicit: personal vs project. Procedures that belong to you (your voice, publishing habits, stakeholder-update standards) are global; procedures that belong to a repo (safe commands, known selectors, seed data, deploy quirks) live with the project. “Open” means portable and inspectable — not “every skill is public” and not “paste secrets into a shared file.”
  • The flywheel: session-to-skill extractor. One shipped skill asks, at the end of a substantial session, “did we learn a recurring, non-obvious procedure worth preserving?” Most of the time the answer should be no (that’s the quality bar); when yes, the procedure becomes a skill candidate instead of disappearing into chat history. Same compounding logic as Open Brain, applied to procedures.
  • Differentiation claim: the value isn’t “skills exist” — it’s portable procedures as an operating layer: one markdown source of truth that Cursor rules / claude.md / Codex instructions can be generated from, so they stop drifting into separate copies.

How a Skill Is Structured (the reusable template)

Per the launch, every file in the library is built to carry the same six contract elements — this is the portable part worth copying regardless of whether you use Open Skills itself:

  • Trigger — when to load/run the skill.
  • Anti-trigger — when not to run it (the piece most SOPs and prompts omit).
  • Owned job — the single contract the skill is responsible for.
  • Required tools/files — what it needs to operate.
  • Boundaries + output spec — limits, and what the result should look like.
  • Verification — the proof standard that gates “done.”

Three worked examples from the talk:

  • Current-information search: use live search when a claim is recent / pricing may have changed / a software version matters / training data may be stale; compare sources, show the date, separate confirmed facts from inference, and let uncertainty block publishing.
  • Personal voice: name the real samples to read, phrases to avoid, sentence length, argument structure, and the “fake AI language” to strip — instead of “write in my voice,” which forces the model to guess.
  • Browser QA: open the actual route, check the console, check mobile, verify the changed workflow, capture screenshots, report the evidence — instead of “test the page,” which invites “looks fine.”

Open Skills vs Open Brain

  • Open Brain = memory layer (context, project, people, decision history, prior work). Most second-brain tools were built for human readers, not as agent-readable memory infrastructure.
  • Open Skills = procedure layer (how to research/write/build/test/publish/report). Most SOPs, checklists, and docs are human-readable but not packaged as agent-operable procedures (no triggers, no when-not-to-run, no required tools, no output spec, no verification, no clean portability).
  • The power is the pair: Open Brain gives the agent the context; Open Skills gives it the procedure — both portable across a multi-model world so you’re not locked into one vendor’s memory/workflow assumptions.

Try It

  • Run the decision rule: do something with an agent once and a prompt is fine; doing it repeatedly across Codex/Claude Code/Cursor means write it as a skill so it stops drifting.
  • Convert one painful re-explanation into a skill using the six-element template above (trigger / anti-trigger / owned job / tools / boundaries+output / verification). Start with your highest-frequency re-explanation (voice, testing standard, or publish checklist).
  • Add a verification clause to an existing skill: “do not call this done unless <specific evidence> exists.” Pick the one task where the agent most often says “done” prematurely.
  • Set scope deliberately: put personal procedures global, project procedures in the repo, so your context layer doesn’t become a mixed pile of yours-and-the-team’s rules.
  • Install the flywheel: at the end of substantial sessions, ask whether a recurring, non-obvious procedure emerged — and only then promote it to a skill candidate.

Open Questions

  • The exact Open Skills repo/landing URL, license, and hosting model are not stated in the transcript (creator points to an on-screen URL only).^[inferred]
  • Whether the skill.md convention is byte-compatible with Anthropic’s official Agent Skills SKILL.md format, or a parallel convention, is not specified.^[inferred]

Graph View

Backlinks