Marketplace
Install workflows and personas somebody else wrote — and publish your own.
A pack is a set of workflows and personas somebody wrote and published for anyone to use. Install one into your organization and from that moment the copies are yours: edit them, rename them, delete them. Nothing about them stays owned by the marketplace, and nothing about them ever changes on its own.
Packs are free. There is no paid tier and no marketplace cut.
Installing one
Open the Marketplace, pick one, and read the screen before you press Install. It shows four things, and each is there because an install is a real decision:
- Every step it would add, drawn in Peractor's own step vocabulary rather than the author's description — so a step that runs a shell command, or posts to one of your connectors, says so.
- What it needs that you do not have — statuses, notifiers, a connected repository. You can install anyway; a workflow that names a status you have not made simply will not move your board until you make it.
- What was checked, and by which rules.
- A second confirmation if the pack runs shell commands — the one thing an install leaves behind that runs on your infrastructure.
Everything lands in your organization's shared library, under a new category named after the pack, so it is easy to find and easy to remove. Installed workflows are not automatically picked for your projects — picking is still your decision, on each project's settings.
Updates, and why nothing updates itself
When an author publishes a new version, your installed list says so and waits. Press Update and you get the same kind of screen: what would be rewritten, and the changelog for every version between yours and the new one — not just the newest, because the version you skipped is exactly the one you need to read about.
- Anything you have edited is left alone. Peractor remembers what each record looked like when it was installed; if yours no longer matches, it is yours, and an update skips it and tells you it did. The other records still update — editing one workflow does not cost you fixes to the other nine.
- If a new version drops a record you have, it says so and deletes nothing. That workflow may be one you run.
What the checks check
Installing a pack means running a stranger's instructions on your infrastructure with your credentials — closer to a CI configuration or an editor extension than to a theme. Every version is scanned before it can be listed, and a version that fails is not published at all.
The badge says "Checked — no known risky patterns". It deliberately does not say "safe": an automated scan cannot promise that, and the first pack to abuse the promise would be the one wearing the badge.
| Rule | Why |
|---|---|
| No web address in text an agent will read | An agent told to fetch a URL is an agent the author can steer after the pack was checked. This is the most important rule here. |
| No text imitating Peractor's own instructions | A persona is a system prompt. One claiming to be the host's is an escalation. |
| No command that downloads, escalates, or reads your credentials | A command step is a shell on your infrastructure. Piping a download into it, sudo, reads of your keys or environment files, and encode-then-execute are all refused. |
| Notifications go to your connectors | A notify step names one of your connectors, never a literal address — an address the author chose is a pipe out of your organization. |
| No secret pasted into a prompt or a command | Secrets belong in connector configuration. Naming one in text moves its value somewhere it can be read. |
| No repository or account hardcoded by the author | It is a leak by them and a broken install for everyone else. |
Rules are versioned. When one is added, packs published earlier read as checked under an older rule set until they are looked at again — a rule that only applied to future publishes would protect nobody already installed.
If you find something a check missed, report the pack. A report can take it down, which delists it and refuses new installs while leaving every existing install exactly alone.
Publishing your own
From the Marketplace, choose Publish a pack. The form lists everything your organization could share — its shared library and each project's, every group headed with whose it is. Pick the workflows, personas and skills you want, and write the listing. The pack is published under your organization's name, and any of its admins can publish the next version. Two things happen before it goes out:
- What you picked is closed over. A workflow brings what it uses: the personas its steps name, and the workflows its lanes run, are ticked along with it, and stay ticked while it is — the form tells you which workflow is holding one if you try to leave it out. If a workflow names something your organization does not have, the publish is refused rather than shipped broken — a pack that installs into a silent failure is worse than one that would not publish.
- The checks run, and tell you the item, the line, and the reason for anything they refuse.
Every version needs a changelog entry. It is not optional: on the other end, somebody is being asked to accept a rewrite of their configuration, and an update prompt with nothing to read is a prompt nobody can answer.
Versions are immutable. To change something, publish another.
Managing what you published
Your organization's packs head the Marketplace under Published by its name, including any it has taken off the marketplace. From a pack's page, an admin can:
- Publish a new version. The form starts from what the last version carried — every workflow, persona and skill in it already ticked — so nothing is dropped by being forgotten. Add or remove what you like and say what changed.
- Unpublish it. It leaves the marketplace and nobody new can install it. Organizations that installed it keep everything it gave them. Publishing a new version lists it again.