# Coding agents

How brewless/laravel teaches Claude Code, Codex, Cursor and other coding agents to deploy and run your application on Brewless.


A coding agent that works on your project, such as Claude Code, Codex, Cursor, GitHub Copilot or Junie, can deploy your application, read its logs and change its configuration with the `brewless` client. The `brewless/laravel` package, from 0.9.0, brings what the agent needs to know for that: a short guideline that is always loaded, and four skills that it loads when a task calls for one.

## With Laravel Boost

[Laravel Boost](https://laravel.com/docs/boost) finds them by itself. Run its installer and choose `brewless/laravel` among the third-party packages:

```bash
composer require brewless/laravel:^0.9
php artisan boost:install
```

Boost writes the guideline into your `AGENTS.md` or `CLAUDE.md`. It writes the skills into the folder each of your agents reads, such as `.agents/skills`, `.claude/skills` or `.cursor/skills`. After updating the package, `php artisan boost:update` brings them up to date.

## Without Laravel Boost

Publish the skills to where your agent looks for them:

```bash
php artisan vendor:publish --tag=brewless-skills          # .agents/skills: Codex, Amp, OpenCode, Zed and others
php artisan vendor:publish --tag=brewless-skills-claude   # .claude/skills: Claude Code
```

The skills follow the [Agent Skills](https://agentskills.io) format, a folder per skill with a `SKILL.md`, so any agent that reads that format can use them.

## The skills

| Skill | What it covers |
| --- | --- |
| `brewless-deployment` | `deploy`, `plan`, `releases` and `rollback`, the steps of a release, build and release commands, deploying from a pipeline, and why a release failed |
| `brewless-configuration` | Variables and secrets with `env:pull` and `env:push`, `brewless.yml`, container sizes, the PHP version and your own `docker/` server files |
| `brewless-operations` | `logs`, running a command, queues and the schedule, scaling, domains and DNS records |
| `brewless-databases` | The database, migrations, queues, buckets, backups, the cache, the Private Network and a database per tenant |

## What the agent is told to keep to

The guideline that is always loaded holds the rules an agent keeps on Brewless:

- **It asks before it changes an environment.** It never deploys, rolls back, pushes variables, scales, sets a domain or DNS record up, or runs a command on production unless you asked for that, on that environment. Reading is fine by itself: `plan`, `releases`, `logs` and `env:pull`.
- It never passes `--force` to skip a question you did not answer.
- It never puts a secret in `brewless.yml` or in the repository; secrets go into your Secret Manager with `brewless env:push`.
- It does not rely on the local disk of a container, and keeps files in a bucket.
- It does not turn on FrankenPHP's worker mode or Laravel Octane, which Brewless refuses.
- It leaves the routes of the package (`/_ops/...` and `POST /`) alone, and runs migrations as release commands.

> [!NOTE]
> The agent works as you: the client uses the sign-in of your machine, or the pipeline token in `BREWLESS_API_TOKEN`. What it does is written to the audit trail under your name, as if you had done it yourself.