Bot Creation Mode

What it is

Bot Creation Mode turns one sentence about a job into a working bot. You describe what you want handled, a guided interview asks a couple of questions, shows you the whole bot, and — once you say yes — builds it: its own hub in your sidebar, already loaded with a persona, the knowledge it needs, and the right skills.

The point is that nothing is left to set up. You open the new hub and start working.

Where to find it

Where it lives

The New Bot row in the Agent Tools sidebar group, beside Overseers and Swarms. It is in development and hidden until you switch it on (Settings → Features → Bot Creation Mode).

Clicking it opens the Bot Builder interview instantly — its greeting and first question appear with no model wait, and nothing is spent until you reply.

How it behaves

What a bot actually is

A bot is an ordinary project folder that has been pre-filled. That is the whole trick: Claude Code already loads a folder's instructions, documents and skills on its own, so no wiring is needed.

What the bot carries	Where it lives	How it reaches the bot
Its job description (the persona)	CLAUDE.md in the bot's folder	Loaded automatically for every session there
Knowledge it always needs	.claude/docs/*.md	Injected into every conversation
Bulk reference material	.claude/docs/rag/*.md	Only a table of contents is injected; the bot reads a file on demand
Skills scoped to this bot	.claude/skills/<name>/SKILL.md	Loaded as folder-scoped skills

Bots are created in a Bots subfolder of your default projects folder and grouped in the sidebar under a Bots divider, so they sit alongside your normal projects without cluttering them.

How skills work here

This is the part that surprises people, so it is worth being precise.

• Skills you already have are never copied into a bot. Every installed skill is already available in every session, everywhere — copying one in would add nothing, create two skills with the same name for the model to choose between, and freeze a stale duplicate that drifts from the real one. Instead the bot's persona names the relevant skills and says when to reach for each.
• A skill you are missing can be installed into that one bot, without touching your global set. You get a one-time approval request for each, because an installed skill's files run inside the assistant's context — that gate is deliberate and is never skipped.
• A skill can be written fresh for the bot. When a bot needs a procedure nobody has written down — the exact steps of your particular workflow — the interview writes it as a small skill inside the bot's own folder.

A bot-local skill shows up in the Skills panel's This project tab when you open that bot. It does not appear in your Installed list, and it does not auto-update — it is a snapshot, which for a bot is usually what you want.

Safety

Anything the interview fetches from the web or a shared document is written into the bot's knowledge as clearly-marked untrusted reference material, and the bot is told never to treat it as instructions. Fetched content becomes standing context for every future conversation with that bot, so this matters: without it, a booby-trapped page could plant permanent instructions.

Changing a bot later

Just ask it. A bot can edit its own job description and its own knowledge files. You can also edit them from the hub's own documents panel, or in the folder directly — they are plain Markdown.

For agents

The New Bot row is the bot-creator amc-builtin integration (bot-creator.ts) — rendersPanel: false, non-spawnable, parentGroupId: 'agent-tools'. Visibility is gated by the bot-creation-mode unreleased feature via UNRELEASED_PROJECT_GATES (project-visibility.ts), never a raw settings read. Its click is intercepted at setActiveProject via maybeHandleSidebarAction (sidebar-action-rows.ts) → SIDEBAR_ACTION_ROWS['__bot_creator__'] = 'super-prompt:bot-builder-interview', handled in useAppCustomEvents.ts.

The interview body ships as the bot-builder-interview prompt in resources/super-prompts.json and does the building itself over the local control server. Two backend affordances exist for it:

• POST /dividers accepts an optional systemTag, routing to the idempotent, race-safe ensureDividerBySystemTag so the "Bots" group is created once rather than duplicated per bot. App-managed tags (amc_builtins, my_automations) are refused — see RESERVED_DIVIDER_SYSTEM_TAGS in divider-branding.ts.
• POST /skills/install accepts an optional projectId, installing into that hub's .claude/skills instead of the global root. The caller names a project, never a path: installed skill files run inside Claude's context and the install pipeline's file allowlist includes .mjs/.cjs/.js, so a caller-supplied destination would be an arbitrary-file-write primitive. skill-install-destination.ts derives the directory from a project row and refuses an unknown or soft-deleted project, an empty workdir, and a sentinel that maps to no real directory. The route resolves once to fail fast, stores only the project id, and the approve-time handler re-resolves. skills.install stays in NON_TOGGLEABLE_CLI_ACTION_KINDS.

Bots themselves are ordinary projects — there is no bot table, no bot sentinel, and no new spawn path.

Related

A bot is an ordinary project, so everything that is true of projects, skills and the fleet agents still applies. use-skills.md covers the Skills browser — finding, installing, editing and removing skills, including the project-scoped ones a bot carries. overseers.md and swarm.md cover the two neighbours the New Bot row sits beside in the Agent Tools group.