New here, or not into command lines? Start on the skillc site → — a plain-language walkthrough with a live demo. Nothing to install to look. Come back here when you want the details.
You got Claude doing something just right. You share it, and for everyone else it falls flat, because it quietly leaned on your setup. skillc is a skill that makes skills: tell it what you want, show it a couple of examples you like, and it hands you one file you can send to anyone.
What makes the file different is what is inside it. It does not carry finished instructions; it carries the examples you approved, plus a recipe. The first time someone uses it, their Claude rebuilds the skill against its own setup, tests itself on a few examples it was never shown, and reports a score. So the skill works there, or it says plainly that it does not, instead of quietly doing the wrong thing.
Install it once, like any skill.
- Claude Code:
/plugin marketplace add baron-3dl/skillc, then/plugin install skillc@skillc. - claude.ai: download skillc.zip, turn on "Code Execution and File Creation" (Settings, then Capabilities), then upload the zip under Customize, then Skills (the "+" button, then "Upload a skill").
- OpenCode: unzip skillc.zip into
~/.claude/skills/; it is picked up automatically.
Skills work on every Claude plan, Free included. The claude.ai Code Execution switch is a one-time toggle.
Just ask, in plain words:
skillc, make me a skill that writes my emails in my voice
It asks a few questions (what you want, a couple of examples you like, your taste), shows you a test, and you say "yes" or "tweak that." Then it hands you the finished skill as one file.
Send the file to anyone. They install it the same way you installed skillc above. The first time they use it, it sets itself up against their Claude, grades itself on examples you approved, and tells them how well it transferred. If it cannot work there, it says so instead of quietly doing the wrong thing.
If you would rather not install anything, skillc also runs as a paste-in prompt: copy make-a-skill.md into a chat and answer its questions. Same builder, no setup. The skill it gives you can be pasted the same way, or saved in a Project to reuse.
The install above uses skillc's Claude Code plugin marketplace, which also lets you version
and distribute skills as files. The worked example skills are a separate plugin,
skillc-examples (voice, explain-plainly, commit-message); install it too if you want the
demos:
/plugin install skillc-examples@skillc
Update later with /plugin marketplace update. Or clone the repo as a plain skill
instead:
git clone https://github.com/baron-3dl/skillc ~/.claude/skills/skillc
Author a shareable skill. With the builder installed, tell Claude what you want to capture. The input can be a skill you already run, a few examples you like, or a style you describe:
build a skill from these examples
build a self-building skill from <a skill you already have>
Claude follows seed/builder.skill.md: it gathers approved examples (by running a skill
you have, taking examples you paste, or drafting and letting you correct), buckets them by
behavioral move, holds a few back as acceptance examples, declares any genuinely local
dependencies as binds, distills your corrections into checks, and writes one file:
<name>.selfbuild.SKILL.md. This is the same builder as the make-a-skill prompt at the
top, just installed instead of pasted.
Share it. Send that one file. There is nothing else to ship. The receiver drops it
in ~/.claude/skills/<name>/, uploads it on the claude.ai skills page, or keeps it in
a repo's .claude/skills/.
Use one you received. Install it and use the skill normally. The first time, before
its first answer, it runs its own rebuild recipe (seed/rebuild.skill.md): it resolves
any binds against your tools, rebuilds its instructions against the author's build
examples in your session, scores the held-back acceptance examples, and states one line:
Built. Build examples matched 4 of 4, acceptance score 0.9. Ready.
or, honestly, Built, but could not reach the author's quality here ... with the gap,
or Cannot build: this skill needs <tool>, which is not available here. Then it
answers, checking each answer against the checks before sending.
claude.ai cannot use the plugin marketplace (that is Claude Code only), and the operating point is your account's memory, custom instructions, and active style. It takes a skill as an uploaded ZIP, so the flow is download then upload:
- Turn on code execution: Settings, then Capabilities, then enable "Code Execution and File Creation" (Skills require it).
- Download the skill you want from the
latest release. Each skill is its
own zip:
voice.zip,explain-plainly.zip,commit-message.zip, orskillc.zipfor the builder. - Upload it: Customize, then Skills, then the "+" button, then "Upload a skill", then the zip.
- Use the skill. On first use it self-builds against your web session and reports the one-line outcome, then answers.
Two honest limits on web chat. The self-build runs in a single conversation, so it partly grades against examples it can see (blindness is softer than in Claude Code, which can spawn a separate grader). And binds resolve only against connected tools, not local command-line tools, so a pure-carry skill (voice, explain-plainly) transfers fully while a skill that binds a local-only tool fails loud there, by design.
Making a skill on claude.ai, and sharing it out. You can author there too. Install
skillc.zip (the builder), then in the chat ask it to build a self-building skill from
the one you have been iterating; it harvests examples (you approve each), and with code
execution on it writes the finished <name>.selfbuild.SKILL.md to the session for you to
download. Pure-carry skills build fully here, since your account is the operating point
they should match; a skill that binds a local tool you can still author (you declare the
bind in plain words), you just cannot test that bind without the tool, which is where
Claude Code helps.
Sharing it out is the part claude.ai does not do for you: there is no publish button and
no skill gallery. You distribute the file yourself, either by handing it to people (they
upload it to their own claude.ai or drop it in Claude Code), or by putting it in a GitHub
repo with a .claude-plugin/marketplace.json (as this repo does) so Claude Code users
add it with /plugin marketplace add you/repo and claude.ai users download it from the
release. claude.ai is make-and-use; GitHub is the distribution layer.
A hand-tuned skill picks up hidden dependencies on your setup: your tools, your memory, your custom instructions. It behaves like a dynamically-linked binary. On anyone else's machine those dependencies resolve to something different, or to nothing, and it does not fail loud like a missing shared library; it quietly produces the wrong thing. The fix is to ship source that rebuilds in place, with every dependency declared on purpose: carry what defines the output (bundled in, the same everywhere), bind what is genuinely local (resolved against the receiver, failed loud when missing).
The author approves examples. You give the builder a few real inputs and the output you want for each: run a skill you already use, paste examples you like, or let it draft and correct it. You never write a gold answer from scratch; you bless the good ones. Approved pairs become build examples, grouped by behavioral move; a few are held back as acceptance examples. More good examples in, better skill out. That is your lever.
What gets shipped is one file containing: the definition of good output inlined in full; any local dependencies as binds in plain words; the build examples; the held-back acceptance examples; the checks (the hard rules, kept from your corrections); and the rebuild recipe.
The receiver's Claude rebuilds it. On first use, before answering, it resolves the binds (and stops, naming any that are missing), writes itself instructions and retries until the build examples reproduce, and overrides any local setting that fights the skill (the carried definition is the authority). Then it grades the held-back acceptance examples for the transfer score, reports one line, caches the result, and runs, checking every answer against the checks before sending.
What the receiver sees is one of three outcomes:
- "Built. Build examples matched N of M, acceptance score 0.84. Ready." Use it.
- "Built, but could not reach the author's quality here. Closest: [text]. Missing: [the gaps]." Honest failure; they know not to trust it, and why.
- "Cannot build: this skill needs [tool], which is not available here." Stops instead of producing something wrong.
Who pays what. The author pays once: approving examples, and an optional pre-ship check (rebuild against a clean setup, report the score). The receiver pays a little on first use, then caches. The expensive validation never runs on the receiver.
The full model, section by section, is in FORMAT.md.
SKILL.md: how Claude operates skillc.FORMAT.md: the self-building file, section by section, and the carry/bind and validation models.seed/builder.skill.md: the author-side procedure.seed/rebuild.skill.md: the canonical rebuild recipe, stamped into every shared file and runnable by hand. It is the one part that is trusted by reading, not by rebuilding.examples/: worked self-building skills you can read and run.voice.selfbuild.SKILL.md: pure carry, no binds (a writing voice).explain-plainly.selfbuild.SKILL.md: pure carry, two behavioral moves.commit-message.selfbuild.SKILL.md: adaptive, binds the local ticket tracker.skillc.selfbuild.SKILL.md: skillc hosting itself (the builder, self-building).*.proof.md: the cold-run evidence for each.
The *.skill.src and *.compile.md files are the earlier two-step model (ship source,
compile separately) that the self-building file supersedes.
Every self-building skill measures its own transfer: on first use in a new session it
rebuilds against a few held-back examples and reports an acceptance score from 0 to 1. Run
one on a different model and you get a fresh number, no setup. The runs below are recorded
in full in examples/ -- method, inputs, and result for each:
- voice.selfbuild.proof.md -- the voice example (a dry, unflappable operator) rebuilt and answered in voice at 0.94; under a hostile "be upbeat, use exclamation points, sell it" profile it overrode and refused to sell, scoring 0.93.
- skillc.selfbuild.proof.md -- skillc hosting itself: it rebuilt its own builder and emitted valid self-building skills on Opus, Sonnet, and Haiku, overrode a hostile "summarize the boilerplate" profile while stamping the recipe verbatim, and the loop closed (a file it emitted then rebuilt itself and ran correctly).
- skillc.adversarial.proof.md -- six session-context injection vectors all resisted (0 of 6 backdoors reached a shipped file). The poisoned-seed cells pin the real boundary: the verbatim check verifies fidelity-to-seed, not legitimacy-of-seed, so the seed is trusted by reading, not by rebuilding (Thompson's trusting trust).
- skillc.pairwise.proof.md -- the builder by receiver model grid: 18 of 18 cells rebuilt and landed in-spec. explain-plainly mean 0.95 flat across all nine pairs; voice mean 0.90. The builder barely matters (even Haiku-built files transfer to Opus and Sonnet receivers); the model is a swappable operating point.
Also in those runs: explain-plainly rebuilt itself cold and explained a bloom filter at
0.95; commit-message, in a session with no tracker, failed loud rather than guess a ticket.
It is all in the open. Rebuild any of these on your own model and send the score back: open an issue with what you saw, or a pull request that adds examples or tightens a skill's checks. Those go into the file and ship to everyone.
MIT. See LICENSE.