--- title: Connect your agent and get the material description: Start the AI path: an empty site, an agent connected to it, and the prototype you are going to turn into a real Quilium site. updated: 2026-07-31 prev: quickstart next: ai-architect --- This is the first of eleven tutorials in which an agent builds a complete site with you, one page of the site at a time. By the end of this one nothing is built yet, and that is deliberate: you have an empty site, an agent that can prove it sees that site, and the design material on your disk.
Live example: Lisière. The AI path builds Lisière, an independent long-form review — a home page that is a collection index, articles with contributors, sections, a form, and a second language added at the end. Its HTML prototype and its design system are the starting material.
## What you will have at the end An empty Quilium site, a local project, an agent connected over MCP with the Quilium skills installed, and the prototype running in a browser next to it. ## 1. Get set up You need an agent that can run commands and read files in a folder. This tutorial was written with **Claude Code on Opus 5**; Codex, Cursor and the others work the same way. What the tutorial gives you is the prompts and the result to expect — not a dependency on one tool. Then get the starting material and the CLI. The prototype and the brand material live in a public repository: seven HTML pages, the shared assets, the brand guidelines and the component catalogue. ```bash git clone https://github.com/quiliumio/lisiere-ai-path.git cd lisiere-ai-path npm i -g quilium # install or update quilium login ``` `quilium login` opens your browser, you approve, and the CLI keeps itself signed in from there. If you already did the [Quickstart](/en/docs/quickstart) you are logged in — run it anyway, it is idempotent, and `npm i -g` updates a CLI you installed weeks ago. Here is what you just cloned: ```text lisiere-ai-path/ ├── proto/ 7 pages, the whole site as flat HTML │ ├── index.html home: featured piece, then the feed │ ├── article.html an article, with its contributor │ ├── section.html one section's index │ ├── the-review.html editorial line and workshop │ ├── contributors.html who writes it │ ├── newsletter.html the subscription form │ ├── thank-you.html where the form lands │ └── assets/ site.css, site.js, the Tailwind config, 11 images ├── branding/ │ ├── brand-guidelines.html voice, colours, type, the logo │ └── design-system.html every component, catalogued ├── package.json one script, to serve the prototype └── README.md ``` Two folders, and no framework in sight. That is the whole starting material: a designer's deliverable, which is what you would actually be handed. ## 2. Look at the prototype Serve the folder and open it: ```bash npm run proto ``` That is a one-line static server on port 9055, so `http://localhost:9055/proto/` is the prototype and `http://localhost:9055/branding/` is the brand material. Serve the project root rather than `proto/`, or the branding pages lose the images they share with the prototype. Read one page properly. You should recognise the shape of the site: a home that leads with a featured piece and a feed, article pages, a contributors page, a subscription form. That structure is what the next tutorial turns into a model.
The prototype is monolingual, on purpose. Lisière ends up bilingual, but the second language is the last tutorial of the path — retrofitting it is the situation you actually meet. There is no language switcher in the prototype either; the agent designs one from the design system when the time comes.
## 3. Connect your agent to Quilium Quilium runs a hosted MCP server. You add its URL once, authorise it with your Quilium account, and the agent can then work on every site you have access to. ```text https://mcp.quilium.io/mcp ``` In Claude, open the connector settings and add a custom connector with that URL. This is the path that works everywhere — claude.ai, Claude Desktop, Claude Code and Claude for Work. Claude Code also accepts a one-line install, which is convenient but **only works there**: ```bash claude mcp add --transport http quilium https://mcp.quilium.io/mcp ``` Authorising happens in the browser: your agent opens a Quilium sign-in window, you approve, and the connection is live. The agent inherits your access — the sites your account can open, nothing more.
Not using Claude? ChatGPT, Cursor, VS Code and the other MCP clients take the same URL, in their own settings. Connect an agent over MCP has the exact path for each, links to their official documentation, and the troubleshooting table.
## 4. Install the Quilium skills ```bash npx skills add quiliumio/quilium-skills -y ``` Run it from the project root. Two skills come down, and you want both: `quilium-builder` for the structure and the templates, `quilium-webmaster` for the content work that follows. The `-y` installs to every agent already on your machine, and spares you a selection screen where nothing is ticked the first time round. ```text ◇ Installed 2 skills ────────────────────────────────────────────────╮ │ │ │ ✓ lisiere-ai-path/.agents/skills/quilium-builder │ │ universal: Codex, Cursor, Amp, Antigravity +12 more │ │ symlinked: Claude Code │ │ ✓ lisiere-ai-path/.agents/skills/quilium-webmaster │ │ universal: Codex, Cursor, Amp, Antigravity +12 more │ │ symlinked: Claude Code │ │ │ ├─────────────────────────────────────────────────────────────────────╯ └ Done! Review skills before use; they run with full agent permissions. ``` The files land in `.agents/skills/`, which most agents read directly, and the installer symlinks them into the conventions of the ones that expect their own folder. Two things follow from that: the install is **per project**, so you run it again in the next one, and the skills are **files you can read** — open `SKILL.md` if you want to know what your agent has been told. Restart your agent afterwards: skills are discovered at startup, so one installed mid-session does not load.
Two different things are called "skills". The ones you just installed are process skills: how to work, in what order, which traps to avoid. The ones the MCP server serves through get-skills and get-skill are documentation: specifications, examples and best practices, maintained by Quilium, always current, and referenced from inside the installed ones. Installing the first does not replace loading the second.
## 5. Create the site Start your agent from inside the folder you cloned, and give it the first prompt of the build: ```prompt Create a Quilium website named "Lisiere with ai" and initialize it into a "quilium" directory. ``` One sentence, and it covers both halves of the job: the site is created on your account over MCP, and the project is checked out on your disk by the CLI. Here is the run, as it happened: ```text ⏺ get-me() ⎿ signed in — personal account, plus 2 organisations you own ⏺ Creating a site is real and billable, so I am not going to guess the owner. Personal account, or one of your two organisations? > The organisation. ⏺ create-website(name: "Lisiere with ai", owner_type: "organisation", organisation_id: "") ⎿ id: engine: liquid deployState: deploying cliInit: quilium init "" --name "Lisiere with ai" --dir "lisiere-with-ai" onboarding_url: https://account.quilium.io/sites//onboarding ⏺ get-website(website: "") ⎿ deployState: deploy_success ⏺ Bash(quilium init "" --name "Lisiere with ai" --dir "quilium") ⎿ Setting up project in 'quilium' ✓ quilium/quilium.json created. ✓ Template successfully pulled. (6 files) ⏺ Done — site deployed and checked out into quilium/. Open the backoffice: https://account.quilium.io/sites//onboarding ``` Four things in there are worth naming. The agent **asked before creating**. A site is a real, billable object, and `create-website` says so in its own description — a well-behaved agent stops on the one decision it cannot infer. It **waited for the deployment**. A fresh site answers `deploying` and is not usable until it answers `deploy_success`; polling is part of the procedure, not politeness. It **handed you the backoffice link**. That `onboarding_url` comes back in the creation response, so you never have to go looking for the new site in the dashboard. And it **overrode the directory**. The `cliInit` command the API hands back ends in `--dir "lisiere-with-ai"`, derived from the site name. You asked for `quilium`, so that is what it used — which is the layout every later tutorial assumes: ```text lisiere-ai-path/ ├── proto/ the HTML prototype ├── branding/ brand guidelines and design system └── quilium/ the site ``` Open the link the agent gave you and the site is there, active and deployed, its health check already green, with one line of activity: the site was created. ![The new site's overview in the dashboard: the name Lisiere with ai, the site active and deployed, a health check reporting nothing blocking, the site ID, and the "Plug in your assistant" card.](/thumbs/4dc91320-aa3f-11f1-9597-0f6462e35a80.png) The right-hand column is worth a glance now, because it saves you a search later: the **site ID**, a **Set up the connection** button holding the MCP URL and the per-client instructions, and a **Developer?** line carrying the same `quilium init` command the agent just ran. ### What an empty site actually contains Six files, and a `quilium.json` that holds an ID and a name — no secret, nothing to keep out of a repository: ```text quilium/ ├── quilium.json ├── layout.liquid the page chrome ├── default.liquid the only page-type ├── _contents.liquid the block dispatcher ├── _sitemap.liquid ├── 404.html └── public/robots.txt ``` Forty-seven lines of Liquid in total. Ask the agent what the site knows about itself and it is just as short: one page-type, `default`, with a `row1` and a `footer` drop-zone; no content-types; no collections; one page, and it is called *From Scratch !*. The whole extension mechanism is one of those lines: ```liquid {% for content in section %}{% if content.template %}{% include content.template %}{% endif %}{% endfor %} ``` A page holds blocks, each block names its own template, and `_contents` includes it. Adding a content-type means adding one file under `elements/` — never editing this loop. Everything the next ten tutorials build hangs off that. ### Run it Give the site its own port, next to the prototype's. Add this to `package.json`: ```json "scripts": { "proto": "python3 -m http.server 9055", "quilium": "cd quilium && quilium run 9056" } ``` ```bash npm run quilium ``` ```text Starting Quilium. Use Ctrl+C to stop. Server running at http://localhost:9056 Mode: draft ``` Two servers on two ports, for the rest of the tutorial: the prototype you are porting on 9055, the site you are building on 9056. Open the second one and you get a page — an almost empty one, but a real one, served by Quilium: ```html From Scratch !
``` No content-type exists yet, so the `row1` drop-zone renders nothing and the loop in `_contents` has nothing to loop over. That empty `
` is the hole every following tutorial fills. ## 6. State the ground rules once An agent with the files does better work than an agent with a description. Say where things are and what not to do: ```prompt We are building the Quilium site in quilium/ from the material in this repo. Where things are: - proto/ is the HTML prototype. It is the visual reference of record. - branding/ holds the brand guidelines and the design system. - quilium/ is the site project. Write only in there. How to work: - Before any CMS operation, call get-skills, load every skill relevant to the task, then get-site-settings for this site. - Match the prototype's markup and its class names. Do not invent a section, a component or a piece of copy that is not in it. - This site is English: field keys, labels, slugs, filenames and helper text, all of it. - Explain a structural choice before you make it — a collection, a route, a page-type. I would rather discuss the model than undo it. - Never publish. I decide what goes live. ``` Five of those six lines exist because the opposite happened at least once while this tutorial was being written.
Say it once, not every morning. Most agents read a project file at startup — AGENTS.md, CLAUDE.md — so this belongs at the root of the repository rather than in a message you retype. The site itself gets its own version later, in the site's AI instructions, which every future session inherits whether or not it has your files.
Why each of those lines matters is covered in [Prompting well for Quilium](/en/docs/prompting). ## What you have now An empty site, checked out next to the material it will be built from, an agent that can prove which site it is on, and the skills installed. Next: [The architecture pass](/en/docs/ai-architect), where the decisions get made.