Turns an existing backend — an API, a CLI, an MCP surface — into a skill agents can actually reach. It equips itself before it works, decides whether the thing is worth wrapping at all, and proves each release surface shipped by fetching the published artifact rather than trusting a green build.
This one is internal tooling — the role I equip when Di-Atomic, SpiderIQ or OPVS needs to wrap one of its own backends as a skill. It produces packages. Its sibling propagate launches them.
One backend, from candidate to proven package — and the judgment call that comes first. Most candidates do not need a skill.
toolkit-bootstrap
The intake. Gate on the CLI floor, extract the four READs with their references and scripts, probe the five CALLs, and resolve which house's release map you are under.
skill-intake
The gate. Two questions in order: does this DO something, and is it worth wrapping at all? Score it, record the fired signals, and be willing to say no.
plan-skill
The brief. Research against live sources, never training data, then wait for the owner to sign off before a single file is authored.
build-skill
The seven layers, shape first. Mirror every tree the house declares and hand-mirror the manifest, then assert the pair is in sync rather than eyeballing it.
verify-skill
The pre-publish gates. Packaging, schema drift against the live spec, the server-side security review, tool-name regex, peer chain, pin policy, secrets, ownership diff.
publish-skill
The release. Walk the house's map in its declared order, honour each gate, and move only on an explicit human go.
verify-shipped
The proof step. Fetch each published artifact and grep it. No shipped claim, no card advance, and no handoff before this one passes.
stalled-authoring
The escalation. Stop cleanly with a named gap. A run that halts is recoverable in minutes; one that improvises around a missing input ships something wrong.
A profession doesn't bundle its skills. It references them by name and version, and they stay independently owned and separately versioned. The split below is the one thing worth learning: READ skills are the method, CALL skills are the capability. Installing a SKILL.md gives you documentation. Ability comes from the MCP server plus the brand's own grants.
opvs profession equip @di-atomic/skill-creatorYour first thirty days: run toolkit-bootstrap before anything else and let it fail loudly if a CALL surface isn't wired. Then let the intake gate decline something. The first time it tells you a candidate isn't worth wrapping and you agree with it, the role has already paid for itself.
One thing to know before you equip it. One house is walked, two are desk-checked. Di-Atomic is exercisable end to end today. The OPVS and SpiderIQ release maps are authored from those teams' 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 exists to refuse.
Every @di-atomic skill and profession is authored and proven through this exact method before it goes anywhere near a client. If you want a release process that ends in a fetched artifact instead of a hopeful green build, that's the conversation.
Book a 30-min call with Di-AtomicLaunching a package rather than building one? See propagate.