Grok Bot templates just shipped. Here's the factory.

Grok Bot can now share a Bot as a template. Not a prompt. A recipe.

Ask a Bot to pack itself, or open Bot settings and choose Share as template. It stages an unpublished draft. You review what got packed. Then you publish a public share link. Anyone with the link previews it on x.ai and hits Add to Grok Bot. They get a copy on their account. They do not get your computer, your logins, or your conversation history.

That is the new unit of distribution. The missing piece is a generator that outputs templates instead of slogans.

Forge is that factory. One keyword in. A complete Bot recipe out. Then it offers to create the Bot, or export it as a public template you can share.

Forge is that factory. One keyword in. A complete Bot recipe out. Then it offers to create the Bot, or export it as a public template you can share.

Add the factory: x.ai/bot/uF_uodOFUz9mdv6XDWE70

Add the factory: x.ai/bot/uF_uodOFUz9mdv6XDWE70

What the new template feature actually is

A template is more useful than copying a prompt. It can carry the Bot's identity and operating description, selected memories, skills, routines, and first-party plugins.

It is not a clone.

Travels with the template

• Name, title, description

• Selected convention memories (not chat residue)

• Skills (the how)

• Routines (the when), as job text, not your live schedule ids

• First-party marketplace plugins the job actually needs

Does not travel

• Conversation history

• The cloud computer, files, and /workspace

• Signed-in browser sessions and cookies

• API keys, tokens, and other secrets

• Custom MCP servers, custom scripts, and code

• Chat attachments

Official docs are blunt about the share link: it is public. Anyone who has it can view the shared configuration. Strip API keys, internal URLs, customer data, and anything you would not put in a public document before you publish. Adding a shared Bot accepts the third-party bot terms. SpaceXAI did not create it. You did.

Nothing becomes public when you first click Share. The pack is an unpublished draft. You inspect it, then you publish. If the option is missing, update the Grok Bot app.

Sharability is a design constraint, not a button

If a spec only works because of your Gmail, your Slack, your repo, it is not shareable. It is a private clone with the serial numbers still on it.

A factory has to write for a stranger:

• People, channels, repos, and accounts become placeholders, never real names.

• Changing facts stay in the source system, not in packed memory.

• Whatever cannot travel (which Gmail, which Slack, which repo, which API key) goes into a first-run setup playbook, not a fake memory.

• Plugins must be real marketplace ids. Inventing one means the recipient cannot install the Bot.

• Routines ship as cadence and trigger intent. The recipient confirms before anything fires on their account.

• Test runs do real work, but they must not change an external system until the recipient says so.

The right analogy is a recipe, not a meal. The recipient's Grok Bot reads the recipe and creates an independent Bot inside their account. Their computer, their logins, their approval gates.

Treat a template like software you did not write. Preview the public page. Review it again in the app. Confirm Add to Bot. Recreate custom dependencies yourself. Connect only the accounts the job needs. Run one safe task while watching before you enable routines or anything that sends, publishes, or pays.

Why a factory, not a prompt dump

Most Grok Bot setups fail for the same reason most prompts fail. The spec is a vibe.

"You are a helpful chief of staff." "You handle my inbox." That reads like a job. It is a slogan. No sources, no deliverable, no approval gate, no way to know it worked. Share that and you have shared a general helper with a new name.

The new template feature makes this worse if you pack slogans. A public link that anyone can Add to Grok Bot will copy the drift, the invented plugin, and the missing approval gate into someone else's roster.

So the factory has a quality bar. If the spec could apply to any Bot, rewrite it before you show it. If it would still need a full rewrite after import, it failed.

The spec format: PCTCE

Every generated profile has to contain all five, in operational language. No fluff.

Persona. One named job. Never General Helper. The name organizes, the title is the job, the description is the contract.

Context. Allowed sources in priority order. Accounts and domain facts as placeholders. Changing facts stay in the source system. Packed memory is reusable conventions only. Empty is correct.

Task. The deliverable, where it is saved, and what done looks like. A file path or the source system, not "I'll handle it."

Constraints. Draft first. Sending, publishing, purchasing, deleting, permission changes, and production changes need approval. No guessing. Prefer connectors over the browser. Never invent plugin ids.

Evaluation. Source links, timestamps, a gap list, stopped at the approval gate. Plus a no-data rule and a missing-source rule. "Done" without proof is not done.

This is the same structure that makes a prompt ship on the first try. Applied to a shareable Bot, it is the difference between a coworker someone else can install and a chat window with a job title.

The factory pipeline

Forge does not interview you first. It expands the keyword like an engineered mega-prompt, then offers to create the Bot or export a public template.

1. Parse. Treat the keyword as the outcome to own. inbox is not a personality. It is a draft-only comms job. Classify into one archetype so the Bot cannot become a department: inbox, research brief, monitor / digest, outer-loop coding coordinator, support drafts, content pipeline, account health, bug repro, or ops specialist only if the outcome is still one job. If the ask is already a full job description, tighten it. Do not add scope they did not imply.

2. Diagnose. Name the failure modes before writing: missing context, constraint gaps (would this Bot send, publish, or guess?), hallucination risk (memory instead of a live source), and general-assistant drift. Ask at most one question, and only when two real forks produce different Bots. Otherwise assume the common case, say the assumption, and show a complete spec.

3. Structure. Write PCTCE as a contract. Three layers: non-negotiable rules, the recurring job, and no current assignment inside a shareable template. A template that bakes in this week's ticket is already stale for the next person.

4. Enhance. Look up real marketplace plugins. Keep only what this job needs. Write 1 to 3 skills, each with "Use this when…", source priority, validation, output, failure, approval, and one example of a correct result. Always include first-run setup: check plugins, write convention memories, ask only for missing fill-ins, create routines after confirm, run a safe test. Routines: 0 to 2, event trigger over polling, weekday daytime unless the job is personal or time-critical, no-data silence, no unproven method on a schedule.

5. Deliver. A short readable spec in chat. No JSON dump. Then the factory fork: create this as a new Bot, or export it as a public template. Export packs the generated profile, not Forge's identity. The recipient should be able to Add to Grok Bot and get a working job, not a clone of the generator.

The quality bar (rewrite before you share)

Throw the spec out if any of these are true:

• The description could apply to any Bot

• Any PCTCE slot is missing

• A skill has no validation, no approval boundary, or no example of a correct result

• A routine has no no-data behavior

• A plugin id was invented, or a plugin is packed that the job does not need

• The spec contains a secret, a person's name, or an internal URL

• The Bot would send, publish, or pay without approval

• A complex flow has no first-run playbook for what cannot travel

• The spec would still need a full rewrite to be usable after Add to Grok Bot

That last one is the bar: first-try shippable and shareable. Not a sketch the recipient finishes by hand.

Anti-patterns the generated Bot must refuse: generic helper tone, filling gaps from stale memory, sending without approval, packing unused plugins, scheduling a method that has never been proven on a real run. Banned output tells: no personality fluff, no "as an AI," no unsourced numbers.

Run the factory

Add Forge.

1. Add Forge.

2. Give it a job in one line. A keyword is enough (inbox). A task is better (draft replies to support mail, never send). A job description is best.

3. Read the spec against the quality bar. If a stranger could not install it, it is not a template.

4. Create it on your account, or export it as a public template. Inspect the unpublished draft. Strip anything you would not put in a public document. Then publish the share link.

The recipient flow is the other half of sharability. They open the x.ai preview, read the identity, skills, and routines, hit Add to Grok Bot, fill first-run placeholders, and run one safe test before anything sends.

The good first test is a job you already do by hand every week. Inbox. Support drafts. A Monday research brief. A bug repro Bot. A content pipeline that stops at draft.

One Bot, one job. Skill is how. Routine is when. The description is the contract. The template is the recipe. The share link is how it leaves your account.

Add Forge

Add Forge

godofprompt.ai

godofprompt.ai