With an AI agent

• Claude Code
• Any other agent
• What the agent cannot do for you

A deploy is a list of steps with a few decisions in it — which provider, which region, what the domain is — and a lot of commands that must be right for this site. That is work for an agent with a shell: Claude Code, Cursor's agent, Codex or your own. The deploy kit gives it the files, and the site gives it the instructions.

Claude Code

Every project made from the skeleton carries a skill, .claude/skills/kitloom-deploy/SKILL.md: what a kitloom site needs on a server, the kit's targets and when each fits, the procedure (ask what it cannot know, run the kit, read deploy/README.md, do the steps with the provider's CLI, check the site answers, make the first administrator), and the rules — confirm before anything that costs money or changes DNS, keep the token out of the chat and the repository, run the kit again rather than edit its files. Claude Code reads it when the request is about deploying. In the project:

Deploy this site to a DigitalOcean Droplet in Frankfurt, domain example.com; the DNS is at Cloudflare.

The agent asks what it does not know, runs php artisan kitloom:deploy-kit server --domain=example.com, makes the Droplet with doctl and a filled copy of deploy/cloud-init.yaml as its user data (and deletes the copy), tells you the DNS record to add, puts the server's deploy key on the repository with gh, runs vendor/bin/dep deploy, checks that /up and the admin's login page answer 200, and makes the first administrator with vendor/bin/dep kitloom:user, handing you the password once. With doctl or gh missing, it tells you what to click instead.

Any other agent

The same instructions, pasted into the agent's chat or saved as its project rules (.cursor/rules, AGENTS.md, a system prompt):

This is a kitloom site: a Laravel application that deploys like any Laravel app, plus
uploads that must outlive a deploy, a queue worker, the scheduler every minute, and
Composer packages from a private repository (packages.kitloom.dev, with my token).

The site has a deploy kit. Run `php artisan kitloom:deploy-kit` to see its targets —
server (a VPS on Ubuntu 24.04: DigitalOcean, Hetzner, AWS EC2/Lightsail), laravel-cloud,
forge (Forge or Ploi), docker (any Docker host), digitalocean-app — then
`php artisan kitloom:deploy-kit <target> --domain=<domain>`. It writes the files for this
site; then read deploy/README.md, which is the plan, and follow it.

Rules: ask me what you cannot know (provider, region, domain, where the DNS is, whether
the database comes from WordPress) before you start; never ask me to paste the token, a
password or a key into the chat — the files say where each goes; confirm before anything
that costs money or changes DNS, with the price; keep docker/auth.json, deploy/docker.env
and a filled cloud-init.yaml out of the repository; check that https://<domain>/up and the
admin's login page answer 200 before you say it is done; make the first administrator with
`vendor/bin/dep kitloom:user` or `php artisan kitloom:user --no-interaction` and give me
the password once.

What the agent cannot do for you

• Pay. Making a server, a database cluster, a Space or an app costs money from the first hour; the skill makes the agent name the price and wait for a yes.
• Hold your secrets. The kitloom token goes onto the server (server.sh asks for it, or reads it from the environment cloud-init passes), into docker/auth.json, or into the platform's secrets; the agent passes a file, never the value in its chat.
• Point the DNS, unless the zone is at a provider whose CLI it has (doctl compute domain records create, Cloudflare's API); otherwise it tells you the record.

Once the site is up, the same agent runs it over MCP — posts, SEO, orders — with exactly the rights of its user: AI Agents.