Runs one bounded launch end to end, from any IDE. It acquires its own toolkit and proves it works before it starts, scores whether the release earns a launch at all, then seeds one card that every surface reads from. The hero renders exactly once.
This one is internal tooling — the role I equip when Di-Atomic, SpiderIQ or OPVS launches its own work. If you want the same craft pointed at your releases, the client-facing sibling is delivery-manager.
One launch, start to finish — and the judgment call that comes before it. Not every release earns a launch.
toolkit-bootstrap
The intake. Gate on the CLI floor, extract the nine READs with their references and scripts, wire and probe the seven CALLs. Names the gap loudly if one can't be closed.
launch-intake
The gate. Resolve which brand you're shipping for, verify the delta is real, score it, then commit to a surface list or decline. Declining is the most valuable thing this role does.
seed-launch
The seeder. Create the card, seed the release facts, lay down every stage upfront, produce the blog body and render the hero exactly once, publish, hand off.
work-surface
The worker. One surface only. Read the card first, self-gate on inputs you didn't produce, reuse hero and voice and hook as given, merge-write only your own keys.
stalled-launch
The escalation. Stop cleanly with a named gap. A launch that halts is recoverable in minutes; one that improvises around a missing input ships something wrong nobody catches until a customer does.
three recipes
skill-launch, profession-launch, product-release — each fixes the surface list and the house rules for what is being launched.
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/propagateYour first thirty days: run toolkit-bootstrap before anything else and let it fail loudly if a CALL surface isn't wired. Then let the gate decline something. The first time it tells you a release doesn't earn a launch and you agree with it, the role has already paid for itself.
Two things it will never do. It won't fire a production deploy — it publishes surfaces, deploys to preview, and leaves the site-wide push to a human. And it won't touch client work.
Every @di-atomic skill and profession ships through this exact pipeline, on our own site, before it goes anywhere near a client. If you want a launch process that produces a record instead of five browser tabs, that's the conversation.
Book a 30-min call with Di-AtomicLaunching for clients rather than yourself? See delivery-manager.