WorkerKitHow to publish a kit others can run
A worker that works for you is not yet a kit. What has to be true before publishing, and what the permanent address commits you to afterwards.
Published by WorkerKit. Updated .
A worker that works for you is not a kit. It is a worker that works for you, with your CRM's field names in it and three edge cases hard-coded that only exist at your company.
Turning one into something a stranger can install is a specific piece of work, and most of it is subtraction.
What a kit is, that a working worker is not
| Your worker | A publishable kit | |
|---|---|---|
| The job sentence | Implicit, you know it | Written for a stranger |
| Specifics | Your field names, your team | Generalised or slot-shaped |
| App access | Whatever you granted | The minimum the job needs, justified |
| Edge cases | The ones you hit | The ones anyone would hit |
| Failure behaviour | You notice | Stated in the instruction |
| Maintenance | Optional | A commitment |
The last row is the one people underestimate. A published kit keeps its address for life, so an update lands on the same page and every link keeps working. That permanence cuts both ways: it accumulates reputation, and it accumulates a last-updated date that anyone can read.
The five steps
Describe the job to the AI assistant you already use, connected to the WorkerKit MCP server, and it writes the kit: it picks the apps and the access each one gets, writes the instruction, validates, and publishes it private first, then public when you say so. The API and the CLI take the same steps. Stated that plainly it sounds like the assistant does it all, and the work is in what each step forces you to decide.
1. Write the job sentence for a stranger
One sentence, no "and". If you cannot state it without listing two things, it is two kits and you should publish the better one.
Compare the directory's own: CRM Scribe is *logs your meetings and email threads into the CRM so records stay current without manual data entry.* A reader knows in one line whether it is for them.
2. Pin the apps, and justify each level
Every kit states the apps it uses and the exact access each needs before anyone takes it. This is the part a careful installer actually reads, and the part where carelessness shows.
The discipline: for each app, write down why the job cannot be done at a lower level. If you cannot justify Write, ask for Read. A kit requesting an app its job sentence does not mention is the single clearest signal of a kit not to install, so do not ship one.
3. Decide what stays a slot
Some kits pin a vendor and some leave an open app slot, naming the surface and letting the installer fill it. School Email to Calendar is built that way: it needs email and calendar and does not care whose. That one decision roughly doubles who can use a kit, and it is free to make at authoring time and expensive to retrofit.
4. Write the instruction as if you will not be there
Because you will not be. The five parts that matter are covered in writing an instruction that holds: the job, a definition of done, the edge cases you have actually hit, what to do when unsure, and what it must never do.
The specific discipline for a published kit is removing your specifics while keeping the judgement. Your escalation ladder goes; the rule that ambiguous cases get flagged rather than guessed stays. That rule is the thing you learned, and it is what you are actually publishing.
5. Validate, then publish
Validation catches the mechanical problems. It cannot tell you whether the instruction is good, which is what the next section is for.
What has to be true before you publish
Publishing a kit nobody has run is how a directory fills with things that do not work. A reasonable bar:
| Minimum | Better | |
|---|---|---|
| Runs completed | Enough to have been surprised | 30 or more, across ordinary and odd days |
| Edge cases in the instruction | The ones you hit | Plus the ones you can reason about |
| Access | Justified per app | Reduced at least once from your first guess |
| Model testing | Tried on representative inputs | Results recorded across ordinary and unusual inputs |
| Failure behaviour | Defined | Observed at least once |
The "surprised" line is the real test. If nothing about the worker has surprised you yet, you have not run it enough to know what its instruction is missing. Reading receipts is how you find out.
Describe the testing you have done
Per-model grades are not currently displayed on kit pages. In the kit description, name the models you tested, describe the inputs and record the limits you found. Separate results observed in real runs from what you expect without a run behind it. The distinction behind a model grade still matters: an unsupported performance claim is not evidence.
The failure mode: publishing your configuration
The commonest bad kit is not malicious or broken. It is somebody's working worker with the company name swapped out.
It installs, it runs, and it produces slightly wrong output for everyone else, because it still assumes a ticket taxonomy, a naming convention or a team structure that only existed where it was built. Nothing errors. It is a private kit wearing a public page.
The test before publishing: **read your instruction as somebody at a different company.** Every sentence that stops making sense is either a thing to generalise or a reason to keep the kit private.
The reasonable objection
"Publishing my kit gives away process I spent time working out."
Often true, and it is a real reason to keep something private, which is supported on every plan including Free. The instruction is the strategy in some cases: how you qualify leads, which accounts get special handling.
The counter-case is narrower than enthusiasts claim. It applies when the job generalises, when you will keep the kit current, and when a permanent public page carrying your name is worth something to you. If none of those hold, private is the correct answer and there is no obligation to publish.
When not to publish
- It encodes your specifics. Field names, internal teams, house shorthand.
- You will not maintain it. A stale kit is worse for your name than no kit.
- It has not run enough. Nothing has surprised you yet, so the instruction is missing whatever will.
- The instruction reveals strategy you would not state publicly.
- You are still changing it weekly. Publish when it has settled.
FAQ
How do I publish a kit on WorkerKit?
Describe the job to your AI assistant, connected to the WorkerKit MCP server, and it picks the apps and the access each one gets, writes the instruction, validates, and publishes the kit private first, then public when you say so. A worker you already tuned can be published as a kit with its worker id, and the API and the CLI take the same steps. Public kits get their own page and a permanent address for life.
Do I need to publish a kit to use one I built?
No. Kits can stay private on every plan including Free, and Team plans can share private kits across the team without publishing them. Building for yourself is the common case.
How much should a kit have run before publishing?
Enough that it has surprised you at least once, because the surprises are what the instruction is still missing. Thirty runs across ordinary and unusual days is a reasonable floor, with the edge cases you hit written into the instruction.
What do I put for the per-model grades?
Per-model grades are not currently displayed. Describe your testing and known limits in the kit description instead, including where a model performed poorly.
Can I update a kit after publishing it?
Yes, and updates land on the same page, because a kit keeps its address for life. Each kit page shows when it was first published and when it was last updated, so the last-updated date is part of what a reader judges.