Publishing
Share an alter-ego publicly so other people can fork it.
Publishing an alter-ego puts a template into the public catalog. Anyone with an XO workspace can browse it, fork it, and feed it their own data to make it their own. Publishing is one-way: you share the shape, never the data underneath.
Only the brief and the configuration ship to the public catalog. Your source material (memos, calls, emails, decks) stays in your workspace and is never uploaded, indexed, or readable by anyone else. If you would not want a piece of text in the brief itself to be public, do not put it there.
What gets published, and what stays private
Publishing pushes three things to the catalog:
- The brief. The few paragraphs of plain-English instructions you wrote.
- The configuration. Which runtime, which tools, which output format, any structured prompts.
- Optional sample outputs you mark as shareable. These are drafts you have explicitly cleared, not auto-pulled from your data.
Publishing does not push:
- Your source material. Memos, decks, transcripts, emails, notes: none of it ships.
- Any fine-tuned model weights. Alter-egos are configured, not trained, so there are no weights to leak.
- Any conversation history. The chats you have had with the alter-ego stay private.
A forker gets a clean copy of the brief and configuration. Their alter-ego only starts learning anything about a specific person once they feed it their own data.
When publishing makes sense
The templates that get forked, and earn their author a reputation in the catalog, share a few traits.
- They solve a recognisable surface ("draft a board update," "reply to inbound investor emails") rather than a vague disposition.
- The brief is short and opinionated, not long and hedging.
- They come with at least one sample output that shows what good looks like.
- The author has actually used the template themselves on real work, not just thought through what one would look like.
If you find yourself reaching for the same alter-ego shape across multiple workspaces, or if other people keep asking you for the prompt behind your output, that is the signal to publish.
The publishing flow
Strip identifying detail from the brief
Open the brief and read it as a stranger would. Anything that names a specific person, deal, portfolio company, or internal codename has to come out. Replace with generic placeholders.
The point is not just privacy. A brief loaded with your specifics also forks badly: someone else cannot use a template that keeps referring to your team.
Add a one-paragraph "what this is for" header
Public catalog browsers read the first paragraph and decide whether to keep going. Write that paragraph specifically:
- Who is this template for?
- What surface or disposition does it cover?
- What kind of source data will a forker need to feed it?
A bad header: "This is an alter-ego for writing." A good one: "For founders sending weekly investor updates. Forks well if you have at least three months of past updates to feed it."
Pick sample outputs
Choose one to three sample outputs that show the template at its best. They should be cleared for public sharing: either generic enough that nothing in them is sensitive, or written specifically as samples for the listing.
Do not lift a real deliverable straight out of your work without scrubbing it. Treat samples the way you would treat a public case study.
Set the metadata
Pick a name, a category, and a short tagline. Names that work well are concrete and a touch playful: "The Patient Investor" beats "Long-Term Investor Alter-Ego v3." Categories are dispositions, roles, or surfaces (see From a Template for the breakdown).
Publish
Hit publish. The catalog listing goes live, and anyone with an XO workspace can fork it. You can pull the listing back at any time; existing forks keep working in their owners' workspaces.
After you publish
Forkers can leave notes on the listing: what worked, what they had to override, what kind of source data they fed it. Treat these as the most valuable feedback you will get, because they come from people using the template against real work.
When you update your own brief, you can choose whether to push the update to the catalog or keep it local. Pushing creates a new version of the public template; existing forks see a notice that an update is available but never auto-pull.
A note on attribution and ownership
You own the brief you wrote. The catalog tracks attribution: every fork shows "forked from [your handle]," and every published version has an author. Forkers cannot rebrand your template as their own without forking it first; the lineage is part of the listing.
If a forker substantially evolves a template (rewrites the brief, changes the surface) and republishes, the catalog treats it as a derivative and credits both authors. The bar for "substantially evolved" is the catalog editors' call, not yours.
What not to publish
A few patterns the catalog does not need more of, and that tend to get reported and pulled:
- "Be me" templates with no clear surface. They fork badly because the brief is doing zero work.
- Templates with hidden ideological loading. State your stance in the header; do not bury it.
- Templates that try to override safety or content policies on the underlying runtime. Those get pulled fast.
- Wrapper templates that re-publish someone else's brief with a one-line tweak. Fork, evolve, and republish as a derivative instead.
Publishing is a small act with a long tail. The templates from the first wave of XO users still show up in fork chains a year later. Write the brief you would have wanted on your first day.