Skills
Fifteen skills — one per module and one for the wizard itself — copied into the directory your coding agent reads, and recorded in the app's lock so a later run can tell its own installs from yours.
Every module in this repository carries a skill/ directory, and the wizard copies the ones you
picked into the skills directory of the coding agent you picked — chatfuel-deals,
chatfuel-contacts, one per module. Each holds that module's structure, the GraphQL operations it
uses and the traps in the API behind it. One more comes with every app whatever you picked:
chatfuel-update, which is about the app's relationship to the wizard rather than about anything
the app does.
The fifteen skills
core is installed on every run and has no interface of its own. It is also implicit in every
module's dependencies, which is why no manifest lists it: everything else builds on its transport,
its proxy spec, its bundled schema and its validator, and every other skill's description says so.
| Skill | --modules | What it covers |
|---|---|---|
chatfuel-core | always installed | Auth tokens, the mandatory CORS proxy, HTTP and WebSocket transport, cursor pagination, the bundled schema SDL, shared operations, platform links, the operation validator. |
chatfuel-livechat | livechat | The operator inbox: conversation lists with live updates, per-platform rendering, sending text and attachments, take-over and close-to-flow. |
chatfuel-contacts | contacts | The CRM: the two list engines and when each is wrong, SegmentInput filter trees, the attribute catalog, CSV import and export. |
chatfuel-deals | deals | The pipeline: contacts grouped by the six fixed salesStageV2 stages, per-column paging and totals, optimistic stage moves. Requires contacts. |
chatfuel-bookings | bookings | The calendar over bookingsV2, specialists with weekly hours and Google Calendar sync, the services catalog, availability. |
chatfuel-knowledge-base | knowledge-base | What the AI knows: business info, opening hours, FAQs, the goods catalog, bookable specialists, the character budget. |
chatfuel-automations | automations | Per-scope AI behaviour: 18 channel and entry-point sources, the 16 FuelySetting types, inheritance from the All base, the fan-out subscription. |
chatfuel-flow-builder | flow-builder | The visual editor: flows, canvas blocks, plugin cards, all 16 block and 29 element types, and roughly 230 single-field setters. |
chatfuel-coworker | coworker | The operator's assistant: async send, streaming chunks, the manual tool-approval gate, screen context and frontend actions. |
chatfuel-publishing | publishing | Instagram feed photos, Reels, Stories and carousels, plus the queue and the double-publish guard the API has no answer for. |
chatfuel-ads-optimization | ads-optimization | Event sets over the click-to-WhatsApp automations, and what each reports back to Meta over the Conversions API. |
chatfuel-channels | channels | Which channels a bot is connected to, disconnecting one, and the one-shot platform links that let somebody without dashboard access connect or refresh a channel. |
chatfuel-auth | auth, opt-in | Supabase sign-in, a Chatfuel bot per account, invite links, owner/admin/member roles, and the proxy gate. |
chatfuel-admin | admin, opt-in | The operator panel: workspaces, bots, per-bot access and a health page, behind a password in the server environment. |
chatfuel-update | always installed | Reading what npx @chatfuel/wizard update reports — skipped, overwritten, conflict, regenerate — and resolving the conflicts, which are the files where upstream moved and you had already edited them. |
The two opt-in skills are offered in the picker and never installed by --yes, because both
modules need credentials the wizard cannot invent. Name them to get them.
chatfuel-update hangs off no module on purpose. A module's skill installs only if you picked
that module, and the update story has to be there for every app, so it lives in content/skills/
beside the module trees — which is also what lets an update update it.
Two layouts, one tree
Neither CLI reads the other's skills directory, so the layout follows whichever agent is going to
open the app. --agent claude or --agent codex settles it before anything is copied.
| Instructions file | CLAUDE.md |
| Skills directory | .claude/skills/ |
Claude Code loads its skills directory by itself, so the instructions file names the skills and stops there.
Only one layout is ever written. Copying both would leave two trees to drift apart instead of one
to maintain, so the skills are moved rather than duplicated in the single case that needs it: a
run that started with no agent on PATH at all, wrote Claude's layout for want of a better guess,
and then had you accept the Codex install at the handoff. The move takes the vacated directories
with it, but only while they are empty — a global ~/.claude holds more than ours — and it
rewrites the app's lock so every moved skill still points at the directory it is in.
Project, or your home directory
The wizard asks where the skills go, in the same layout either way: into the scaffolded project,
or into your home directory, which is worth it when you plan to scaffold more than one app and
want one copy of the notes. Under --yes it takes the project without asking.
What a skill directory holds
SKILL.md is the entry point every agent reads first, and it carries a table of what sits beside
it, so nothing in the directory is found by guesswork.
references/ | The long documents: the model, the traps, and — in chatfuel-core — the schema SDL and the possible-types map, which the wizard writes into the directory as it installs it. A domain skill has one file per surface. |
playbooks/ | In every skill: customize.md, the index of knobs for that module, and embed.md, the wiring guide for mounting it inside a host app. |
examples/ | operations.graphql — validated operations to copy as a starting point, because they encode the known quirks. Every skill carries one except chatfuel-admin, which is not a Chatfuel API surface at all, and chatfuel-channels, whose operations are all in chatfuel-core. |
scripts/ | Only in chatfuel-core: validate-operations.mjs, which with no arguments validates its own examples and every sibling chatfuel-* skill's. |
assets/ | Only where a module has a file worth shipping — chatfuel-contacts carries eight rows of sample CSV for a demo import. |
What a second run does to a skill you already have
The app's lock is the record. .chatfuel/lock.json carries a skills entry for every one the run
put on disk: the module it came with, the content path it was copied from, whether it went into
the app or into your home directory, and — for a directory the wizard found and was told to leave
alone — that it is not the wizard's to replace.
That entry is what lets a later run tell its own installs from a directory you wrote yourself. Find one recorded as the wizard's, and the question names the version that put it there and the version about to replace it. Find one the lock does not claim, and the question is blunter, because it was not ours to begin with. Decline either and that one skill is skipped; the rest of the run continues, and a run where you decline every one of them is a run that installed nothing and says so rather than failing.
--yes answers those questions itself, and it answers them differently. A directory this app's
lock records as the wizard's is replaced without asking. A directory the lock does not record is
left exactly as it is — which is the outcome that matters in a project the wizard did not
create, where a chatfuel-* skill of your own would otherwise be deleted by an unattended run.
For coding agents
The wizard ends by handing the project to a coding agent, so the project ships with notes — and this site ships as text for the agent that has not run it yet.
The handoff
Two files come out of the run — a standing brief the agent reads every session, and a one-time setup checklist with every module's guide inlined into it.