The skill that builds your skills.

What is Skill Builder?

Skill Builder is an agent skill whose job is building other agent skills. You describe a process you find yourself repeating — “every time I get a sales call booked, I research the company and write a prep brief” — and it walks you through turning that into a skill your agent can run on demand, every time, the way you would.

It works for brand-new skills and for restructuring existing ones that have outgrown a single SKILL.md. Either way, the output follows the Builder Methods skill conventions: a discoverable description, declared inputs, templated artifacts, steps unpacked into files, and a built-in self-check — so the skill you get is one your agent actually executes well, not a wall of prose it skims.

Everything it produces is plain markdown and folders. Nothing harness-specific — the same skill folder works in Claude Code, Codex, Cursor, and whatever ships next.

Installation

Learn Agent Skills

Skill Builder handles the mechanics — but knowing which processes to turn into skills, and how to design ones that compound, is the real leverage. Two ways I teach that:

• Free workshop: From AI Dabbler to AI-Native — a free ~60-minute workshop on making AI native to everything you do, including how to build your first agent skill.
• Flagship course: Become AI-Native, included with Builder Methods Pro — goes deep on building everything from simple helpers to complex multi-step processes with Agent Skills, until agents are running real work for you.

How it works

Skill Builder runs a five-step process, and every decision along the way uses a recommend-then-confirm format: it leads with its recommended answer and one line of reasoning, plus a couple of alternates, so you can confirm in a word or steer hard when you want to. You should barely have to think unless you want to.

1. Understand the process

It starts by asking for the one thing only you can provide: a plain-language description of the process the skill will be responsible for. High level is fine. From that seed it works out what it can on its own — the job (“every time X happens, produce Y”), what you’d actually say to trigger it, what inputs a run needs, what artifact it produces, and whether your repo already contains examples of the work done by hand (those are gold — a template mined from real past work beats one invented from description).

If you’re restructuring an existing skill instead, it reads the current skill in full and notes where it strains.

2. Design interview

Then it designs the skill with you, one item at a time: the frontmatter description (with the trigger phrases that make the skill discoverable), the name, required inputs (if any), the questions the skill should ask its user each run (if any), realistic examples to build in (if applicable), and the ordered step plan. Nothing moves forward until you’ve confirmed each item.

3. Shape & placement

Two structural decisions, both recommended for you: simple or structured — one SKILL.md for a process it can hold in a page or two, or an orchestrating SKILL.md with steps unpacked into topic-named files when it would otherwise grow too large — and local or global — in one repo’s .agents/skills/, or in ~/.agents/skills/ if you’d ever invoke it from a second repo. Structure has to be earned by real complexity, never added on spec.

4. Build

It writes every file completely, working through the conventions checklist as it goes: the confirmed description and inputs, the skill’s own interview in recommend-then-confirm format, the templated artifact, a self-check, a scope boundary, and progressive disclosure — a lean orchestrator with detail pushed into files that load on demand. No README, no changelog, no stub files — only what a run needs.

5. Verify & hand off

Before declaring the skill done, it runs it once for real — using one of your confirmed example invocations against a real input — and fixes what didn’t work. Then it hands off: how to invoke the skill, plus the improvement loop below.

The conventions

The skills it builds follow a documented canon — a strong default, not a mandate. The highlights:

• Discoverable description. The frontmatter description is the only home for “when to use” — it’s all the agent sees before the skill triggers.
• Order lives in the orchestrator. SKILL.md carries the numbered sequence; step files are topic-named and position-agnostic, so reordering is a one-file edit.
• Templated artifacts. Whatever the skill produces has a defined format — mined from real past examples whenever they exist.
• Progressive disclosure. Lean orchestrator, detail in files that load only when read, every file linked with a note on when to read it.
• A self-check and a scope boundary. The skill verifies its own output against a definition of done, and states what it does not do.

The improvement loop

The first version of any skill is a draft of the process, not the final form. After each real run, notice what chafed — a question that was pointless, a section that always gets edited, an input it should have asked for — and fix the skill in place: “update the skill so that next time it…”

Skills get good by being run, not by being designed. Sections you predicted will go unused, and things you didn’t predict will keep coming up until you make them real. Kill the former, promote the latter.

Next steps

• View the source on GitHub
• Explore other Builder Methods tools