# Skills

> A page of instructions an agent reads before a certain kind of job — written once, read by every agent on the machine.

Every team has things that are only true of them: how code is written here, how
a release goes out, what "done" means, which three files you always forget.

A **skill** is one page saying one of those things, and it is handed to the
agents rather than repeated in every message.

## What a skill is

![settings → skills — this folder's pages, and a row for what has been delivered to the CLIs on this machine](https://beafk.app/docs-shots/skills.webp)

A page with a name, one line saying when to use it, and the instructions
themselves. `deploy`. `house-style`. `writing-migrations`.

An agent reads it **at the moment it needs it**, for the job that needs it. What
reaches a prompt is a short pointer saying which pages exist and how to open
one; the page itself is fetched by the agent that wants it.

Under three hundred tokens a turn, and the page can be re-read halfway through a
job.

## Writing one

**settings → skills**. The screen has a chat of its own: say what the rule is
and let it write the page, then read it and fix the bits it got wrong. That is
faster than typing a page of instructions with your thumbs.

Or write it yourself. It is markdown.

## Machine or project

Same as everywhere else here. A project skill knows that codebase; a machine
skill is the general one you want everywhere. A project skill wins over a
machine skill with the same name.

## Handing them over

The pointer has to be written into the files each agent reads — `AGENTS.md`,
`CLAUDE.md`, and each CLI's own home file. One press does it:

```sh
beafk skills load            # write the pointer where the agents here read it
beafk skills load --files    # …and commit the pages into this repository
```

`--files` is for an agent that has no beafk on its `PATH` — a CI job, somebody
else's laptop. On a machine that can run the command, the binary is enough.

The panel has the same thing under **settings → skills**, including the exact
block your context window pays for.

## beafk's own skills

beafk ships pages about itself — how to read the logs, how to check the machine,
how to add a command, how to set variables, how to run a crew, how to
[hold the files it is editing](https://beafk.app/docs/holding-files.md). Every agent on the machine
can read them, which is why "add the deploy command to the launcher" works
without you explaining what a launcher is.

```sh
beafk skills                 # what this machine can be asked for
beafk skills show read-logs  # one of them, in full
```

Those pages are compiled into the program, so they describe the version that is
running. Updating beafk updates them.

Skills are one of four things beafk describes once and delivers to every agent —
see [keeping every CLI in sync](https://beafk.app/docs/keeping-every-cli-in-sync.md).

---

beafk documentation · Skills and variables · https://beafk.app/docs/skills

In this section:
- Keeping every CLI in sync — https://beafk.app/docs/keeping-every-cli-in-sync.md
- Variables — https://beafk.app/docs/variables.md
- Tool servers — https://beafk.app/docs/tool-servers.md
- Connecting Gmail — https://beafk.app/docs/connecting-gmail.md
- Skills — https://beafk.app/docs/skills.md (this page)

Every page, one line each: https://beafk.app/docs/llms.txt
All of it in one file: https://beafk.app/docs/llms-full.txt