# Skills

> Thirteen skills, one per module, copied into the directory your coding agent reads — with a sidecar that lets a later run tell its own installs from yours.

Page: https://sdk.chatfuel.com/docs/agents/skills
Markdown: https://sdk.chatfuel.com/docs/agents/skills.md

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.

## The thirteen skills [#the-thirteen-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, 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 15 setting 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-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.                                        |

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.

## Two layouts, one tree [#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.

<Tabs items="['Claude Code', 'Codex CLI']">
  <Tab value="Claude Code">
    |                   |                   |
    | ----------------- | ----------------- |
    | 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.
  </Tab>

  <Tab value="Codex CLI">
    |                   |                   |
    | ----------------- | ----------------- |
    | Instructions file | `AGENTS.md`       |
    | Skills directory  | `.agents/skills/` |

    Codex's discovery depends on its version and your config, and the instructions file is read either
    way — so that file spells out the full path to each `SKILL.md` instead of naming it.
  </Tab>
</Tabs>

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.

## Project, or your home directory [#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 [#what-a-skill-directory-holds]

<Files>
  <Folder name=".claude">
    <Folder name="skills">
      <Folder name="chatfuel-core">
        <File name="SKILL.md" />

        <Folder name="references" />

        <Folder name="playbooks" />

        <Folder name="examples" />

        <Folder name="scripts" />

        <File name="chatfuel.skill.json" />
      </Folder>

      <Folder name="chatfuel-contacts" />

      <Folder name="chatfuel-deals" />
    </Folder>
  </Folder>
</Files>

`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, the schema SDL and the possible-types map in `chatfuel-core`, and one file per surface in a domain skill.                                                        |
| `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 ships references and playbooks only. |
| `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.                                                                                    |

## The sidecar [#the-sidecar]

Beside every copy the wizard writes `chatfuel.skill.json`, and it holds three things:

```ts title="packages/wizard/src/scaffold/skills.ts"
interface SkillSidecar {
  module: string;
  wizardVersion: string;
  installedAt: string;
}
```

That is what lets a later run tell its own installs apart from a directory you wrote yourself. On
the second run the wizard reads it back and asks by name, quoting the wizard version that put the
skill there, when it did it, and the version about to replace it. A directory with no sidecar gets
the blunter question, because it was not ours to begin with. Decline either and that one skill is
skipped; the rest of the run continues.

<Callout type="warn">
  `--yes` skips the question. A non-interactive run replaces an existing skill directory without
  asking, so if you have edited one, back it up before re-running the wizard unattended.
</Callout>
