All thirteen
The thirteen modules the wizard can install, what each one adds to the app, and what a module is made of.
Scaffolding subtracts. The wizard copies the whole app, deletes the modules you did not pick,
regenerates the module index, filters the navigation table and prunes the tsconfig paths that
no longer resolve — so what lands on disk is not a template with holes in it. The code you did
not ask for was never written.
Two things arrive whether you asked or not: core, which every module depends on, and anything
a module you picked declares in requires.
The thirteen
--modules takes the wizard's own ids, comma-separated, and refuses an id that is not ready in
the build you are running. --yes picks every ready module except the two opt-in ones.
--modules | In the app | Selected by | What you get |
|---|---|---|---|
core | — | always | Transport and auth, the error envelope, pagination, the CORS proxy spec, the bundled schema, the operation validator. No UI. |
livechat | Inbox | default | Chat list, message thread and composer, live over WebSocket. |
contacts | Contacts | default | Three surfaces behind one header — the record table, the bot's field catalog, the audience breakdown — plus a full record page. |
deals | Deals | default | Three views over contacts by sales stage: a kanban board, a table and a forecast. A deal is a contact. |
bookings | Bookings | default | A booking workspace in six sections: calendar, appointments, staff and their weekly hours, services, settings, insights. |
knowledge-base | Knowledge Base | default | A rail of knowledge sources: overview, business profile, the free-text half, FAQ, products, services, team, and the gaps the assistant handed to a human. |
automations | Automations | default | The rail of eighteen sources, the selected source's Default rules and the custom rules on it, and a Test panel that is always open. |
coworker | Coworker | default | The operator's own AI assistant on its own page: it answers with what the operator is looking at, and it can move the app. |
flow-builder | Flow Builder | default | The visual flow editor: pick a flow, read its blocks and connections on a canvas, edit content in the inspector. |
ads-optimization | Ads Optimization | default | Conversion reporting for click-to-WhatsApp ads: the default event set that covers every ad, and custom sets that claim ads by id and override it. |
publishing | Publishing | default | Instagram feed photos, Reels, Stories and carousels, written against a live preview and published on the spot or put in a queue. |
auth | Team | opt-in | Sign-in on your own Supabase project. Every account that signs up gets a Chatfuel bot of its own and can create more; colleagues arrive by invite as owner, admin or member. |
admin | Admin | opt-in | The account behind this deployment's own token: every workspace and bot, their channels, and a health page — behind a password held in the server environment. |
The two you have to ask for
auth and admin are never installed by --yes, because both need credentials the wizard
cannot invent. Name them:
npx @chatfuel/wizard --modules livechat,contacts,deals,authNeither behaves like the others once installed. auth is hidden: no rail item and no route
of its own — what it changes is who may reach everything else. admin is railHidden: routed
at /admin like any module, and never listed, because the rail is where a product's users go
and an operator's door does not belong on it.
The twelve with a page of their own
core has no page here for the same reason it has no rail item: it has no interface.
- AI AgentAI replies on every channel
- Flow BuilderVisual editor for chat flows
- Knowledge BaseEverything the AI knows
- CopilotAI copilot inside your app
- InboxShared inbox for your team
- ContactsCRM for your audience
- DealsKanban board for sales
- BookingsCalendar for appointments
- PublishingInstagram posts and Reels
- Ads OptimizationAd conversions back to Meta
- AccountsSign-up for your customers
- AdminOperator panel for the account
What a module is made of
A module is a directory holding a manifest, an agent skill and a handoff note, plus a matching
React tree under src/modules/<id>/. There is no state library and no plugin registry, and
modules do not import each other except through a declared requires — today that is deals
needing contacts, and nothing else.
The skill is installed into .claude/skills/ or .agents/skills/ depending on the coding agent
you chose, and the handoff note is inlined into that agent's instructions file, so the agent
that continues the work has the same notes about the API's edges that we do.
How a module is wired to the shell is the rest of that story; your first change walks one end to end.