How 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.
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
The Kit Creator Studio is a no-code builder. Describe the job, pin the apps and the access each one gets, write the instruction, validate, publish. Stated that plainly it sounds like form-filling, 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 grades | Declared honestly | At least one measured |
| 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.
Declared and measured grades
Every kit page grades itself per model, and each grade is marked with where it came from: measured from real runs, or declared by the publisher.
At publication you will mostly have declared grades, which is fine and is exactly why the mark exists. What matters is declaring honestly, including the model where your kit is weaker. See model grade for how readers are told to weigh them.
The incentive here is less perverse than it looks. Uniformly high declared grades buy installs followed by workers that underperform, receipts that show it, and a permanent page carrying your name.
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?
Through the Kit Creator Studio, a no-code builder: describe the job, pin the apps and the access each one gets, write the instruction, then validate and publish. Published 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?
Declare honestly, including where your kit is weaker. Grades are marked measured or declared so readers can weigh them differently, and a uniformly high declared set buys installs followed by receipts that contradict it.
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.