Why this exists
In one working session I turned eight repeated manual workflows into skills. By the end, the durable lesson was not any single skill; it was the craft rules that decide whether a skill actually fires. The description is a trigger matcher, not a summary: write it vague and the skill sits there unused forever. Paths must be absolute or the skill breaks the moment it runs from a different folder. Guardrails must be spelled out ("never overwrite", "drafts only, never send") because an agent will happily fill silence with initiative.
And the one that bit me hardest: personal data belongs in an ask-once config file, never hardcoded. The first version of one skill had my own details baked into the file, which was fine right up until I wanted to share it. This skill packages all of those rules, so every skill I build now starts correct instead of getting corrected later.
How it works
- It mines the workflow you just did The best source is the current conversation: the exact steps, the paths touched, the mistakes made and corrected. Those corrections become the new skill's Rules section. It also pins down a kebab-case name, checks it against every installed skill, and insists on one job per skill.
- It chooses where the skill lives Project-only skills go in the project. Skills useful across workspaces go in one shared library folder, linked into each workspace so an edit propagates everywhere. Generic utilities go user-global.
- It scaffolds a SKILL.md that fires Always a folder, never a loose file. The description carries the literal trigger phrases, quoted. Paths outside the project are absolute. Guardrails are explicit. Personal data lands in an ask-once config the skill loads at step zero.
- It registers and dry-runs Claude Code discovers the skill automatically; agents like Codex do not, so it registers the skill in AGENTS.md as required reading when the workspace serves both. Then one dry run on throwaway input before the skill is trusted.
Step by step (for first-time users)
-
Finish a workflow, then type
/skill-builderThe moment you catch yourself doing something for the second or third time is the moment to run it. Same session works best: the raw material is still in the conversation. - Answer the framing questions Name, trigger phrases, and the one job. If you find yourself saying "and also", you are describing two skills. Split them.
- Confirm the tier It recommends project, shared library, or user-global based on where the workflow makes sense. For the shared tier it creates the links for you, no admin rights needed on Windows.
- Review the guardrails Read the Rules section it drafted. Anything the skill must never do (overwrite, delete, send) should be written down, not assumed.
- Dry-run once, then use it for real It tests the new skill on throwaway input and deletes the test output. Fresh sessions pick the skill up automatically from then on.
Where a skill should live
| The skill... | Tier | What that means |
|---|---|---|
| Only makes sense in this one project | Project | Lives in the project's own skills folder, travels with the repo |
| Useful across several workspaces | Shared library | One real folder, linked into each workspace; edit once, updated everywhere |
| Generic personal utility | User-global | Available in any folder you open, tied to you, not a project |
Honest take
What it does well: The description-as-trigger-matcher rule alone is worth the download. Most skills that "do not work" work fine; they just never activate, because their description reads like a summary instead of a matcher for what a user actually types. The tier system is the other quiet win: the shared-library-plus-links pattern means I maintain one copy of each skill across every workspace, and the ask-once config rule means any skill can be shared publicly without leaking who I am.
What it does not do: It does not invent workflows. It packages one you already have, and it is honest about it: a skill built from a workflow you have never actually done is a guess wearing a frontmatter. It also refuses to edit installed third-party bundles and will extend an existing skill rather than duplicate overlapping triggers, which occasionally means the answer to "build me a new skill" is "no, update this one".
When to use it: The third time you do the same multi-step task by hand. At the end of a session where you corrected the agent more than twice on the same workflow (those corrections are the Rules section, already written). And before sharing any skill, because the craft rules are exactly the things that break on someone else's machine.