I thought two skills shipped. Five weeks, invisible.

I published two skills. Both came back green. Security review 100 out of 100, doctor HEALTHY, zero findings. I moved the cards to Done and went to work on the next thing.

Five weeks later I found out no customer could see either one.

Nothing had crashed. Nothing had errored. The packages were sitting on the registry exactly where I put them, in a state called internal — because tier defaults to internal, not beta, and I had not declared it. A green build told me I was finished. It was answering a different question than the one I was asking.

That gap is why @di-atomic/skill-creator exists.

Who this is for

This one is internal tooling. I built it for the three houses I run — Di-Atomic, SpiderIQ, and OPVS — and I am saying that plainly rather than dressing it up as a product for everyone. If you run more than one codebase that publishes packages agents consume, the problem underneath it will look familiar.

Here's the thing: every one of those houses has real backends already. APIs, CLIs, MCP surfaces. Things that work. What none of them had was the discipline for turning one of those into a skill an agent can actually reach — written down, versioned, and enforceable. It lived in slash commands in one repo's .claude directory, and in my memory of one bad afternoon per trap.

What you hire when you equip it

Skill Creator turns an existing backend into a published skill. That is the job. But the shape of the job is not what I expected when I started writing it down.

It opens by equipping itself. An IDE session starts with an empty toolkit, so the first workflow acquires the tools and proves both halves work before any authoring begins. That sounds like overhead until you measure it. Installing a layered skill with --to lands 74 files, including five executable gating scripts. The same install with --runtime lands one. The single file looks fine. The gate just silently degrades to prose, and you find out much later.

But there's a catch, and it's the part I did not plan for: the most valuable thing this role does is decline.

The intake workflow scores a candidate before a brief exists. Overlap with something already shipped. Whether the target surface is stable. Whether anyone will reuse it. And first, the question that decides the whole bundle shape and cannot be patched afterward — does this thing actually do something, or is it methodology? A low score earns an honest answer: this doesn't need a skill, call the MCP tool directly. A documented decline is a successful run.

The toolkit — nine skills, linked not copied

A profession references its skills by name and range. They stay independently owned and separately versioned, and the split between them is the one thing worth learning.

Five are CALL skills, reached over MCP. These are capability, and OPVS built all of them:

• @opvs-ai/agentboard — the brief card, where the whole authoring cycle lives as shared state

• @opvs-ai/agentdocs — the immutable brief snapshot and the house release map, versioned

• @opvs-ai/agentmemory — brand-private recall of which surface went stale last release

• @opvs-ai/opvs-protocol — the handoff to propagate@profession.md when the package is done

• @opvs-ai/profession — the guild hall

Four are READ skills, extracted into the project and run by your own model:

• @di-atomic/api-docs-writer — README, method reference, changelog. It ships five executable gating scripts, which is exactly why the install flag above matters.

• @di-atomic/copy-engine — the package description and long description

• @di-atomic/voice-builder — brand voice, plus the forbidden-claims linter

• @di-atomic/hook-generator — because a skill's description field is the trigger hook, not decoration

Installing a SKILL.md gives you documentation. Ability comes from the MCP server.

Eight workflows

toolkit-bootstrap acquires the toolkit and resolves which house's release map you are under. skill-intake is the gate. plan-skill produces a research pack and a brief, and waits for the owner to sign off. build-skill authors the seven layers and hand-mirrors the manifest. verify-skill runs the pre-publish gates, including schema drift against the live spec. publish-skill walks the house's release map in order, and only on an explicit human go. verify-shipped is the proof step. stalled-authoring stops cleanly with a named gap.

Now for the part that changed the design.

Three houses, one method, three maps

I assumed publishing was one step. It is one step at Di-Atomic. At OPVS it is eight coordinated surfaces in a fixed order. At SpiderIQ it is four plus a scaffold. Thirteen surfaces across three houses, and both house runbooks independently name the same dominant failure in almost the same words: shipped code is not shipped function.

Upstream puts it more sharply. A log line that says Registered 8 tools is not proof that an agent can call those tools.

So the houses differ only in the release map. That is why there is one publish-skill workflow and three config recipes rather than three forked directories — a fourth house should mean a fourth config, not a fourth workflow. And it is why the eighth workflow exists at all. verify-shipped fetches the published artifact and greps it. Not a status check. Not a 200. The bytes.

Let me show you exactly how that paid off.

While building this, I pointed the gate I was shipping at one of my own live packages. It failed. @di-atomic/url-utils@0.3.2 sits on the registry right now at tier: beta, with visibility: internal and no marketing.author. Published. Healthy. Invisible to every customer.

Same failure class as my five weeks. Found by the thing built to prevent it, one version too late to be smug about. It needs a patch bump and a re-prove, and that is now its own card.

The guild

The address is skill-creator@profession.md.

That address is not decoration either. Release craft is the most transferable knowledge in this stack, and right now every trap in it is one person's memory of one bad afternoon in one repo. That a tool name containing a dot returns HTTP 400 before any reasoning runs, and breaks every brand that loaded the skill. That a caret on a 0.x peer pins the minor and can never match a later one. That publishing from a symlinked path signs and ships a 133-byte empty tarball which then reports HEALTHY.

Every one of those cost somebody a day. None of them should cost the next person anything.

So brand-private outcomes stay private — they go to agentmemory and never leave. Only generalized, anonymized patterns cross into the guild. Three houses contributing to one address is the entire point.

What ships today, honestly

Eight workflows, ten references, six registry items, twenty definition-of-done checklists, and thirty-one explicit out-of-scope lines. Trust state starts at probationary. Security review 100 out of 100, doctor HEALTHY, zero coherence findings.

One house walked, two desk-checked. Di-Atomic is exercisable end to end today. The OPVS and SpiderIQ recipes are authored from their own runbooks and stay labelled desk-checked until a real release runs under each. Claiming three walked houses would be the exact over-claim this role is built to refuse, and I would rather tell you which half is proven.

Bottom line? Equip it and let it decline something.

opvs profession equip @di-atomic/skill-creator

Run toolkit-bootstrap before anything else and let it fail loudly if a surface isn't wired. Then wait for the intake gate to tell you a candidate isn't worth wrapping. The first time you agree with it, the role has paid for itself.

Two things it will not do. It will not publish a blog post, a changelog entry, or a listing page — that is its sibling, @di-atomic/propagate, which is the launch half. Skill Creator produces packages. Propagate launches them.

And it will not tell you something shipped until it has fetched the artifact and read it back.