Build with an AI agent

Port60 templates are unusually good territory for AI coding agents: the whole job is a handful of Liquid files against a machine-readable contract, with a validator that returns structured errors the agent can iterate against, and hard walls (the dialect whitelist, escape-by-default, render budgets, human review) that make the worst an agent can produce a rejected upload, never a broken charity site.

The setup

npx @port60/template-kit create riverside-warm
cd riverside-warm && npm install

The scaffold ships AGENTS.md (and an identical CLAUDE.md), the briefing every serious coding agent reads on entry: the file layout, the contract rules, and the iteration loop. You don’t need to explain the platform to your agent; the scaffold already has.

The loop your agent should run

1. Edit sections/*.liquid, layout.liquid, assets/theme.css, manifest.json.
2. npm run validate:json, machine-readable: {ok, errors[], warnings[], provenSupports}. The agent fixes every error and re-runs until ok: true. This is the platform’s exact upload check, so a clean local pass is a guaranteed clean upload.
3. You watch npm run dev at http://localhost:4400, the same fixtures render reviewers see. Refresh after edits; validation re-runs in the terminal on every save.
4. npm run package, the uploadable <name>-<version>.zip.

A kickoff prompt that works

Read AGENTS.md first. Build me a warm, editorial template for a food-bank charity: generous type, cream background, a photography-led hero. Support the hero, values, cta and events sections, a layout with the member menu island in the header, and ship two looks, “Warm” and “Evening”. After every change run npm run validate:json and fix all errors. Tell me when it validates clean.

For the agent itself

Everything on this site is available as one plain-text file at /llms-full.txt, the guides plus the generated contract reference (sections, islands, context variables, dialect, tokens, manifest schema). Fetch it once into context and build against it.

For section presentation, read the control registry and its JSON, then the exact template manifest. The registry defines meaning and saved addresses; it does not imply every template supports each control. For example, “make the Events heading smaller” may select compact only when that Events section declares it. Save the explicit token at content.presentation.headingScale for the addressed section instance; resetting removes just that key. Never invent numeric sizes or CSS. “Give this section more space” may select spacious at content.presentation.sectionSpacing only when independently declared. This changes outer top/bottom padding, not card gaps or side margins. A combined proposal must validate both controls against the same exact artifact; resetting one must preserve the other and all content. Follow the heading-size guide for inherited values, actual-heading hooks and author-controlled responsive sizes. Passing validation is necessary, but computed browser checks must also prove each option works and reset is exact. These are the same constraints for a human inspector and future agent integration, not a new agent-write API or permission to publish.

What the agent cannot do, by design

Supports flags are proven, not claimed: declaring supports.worship without rendering the worship fixture is a validation error, as is the reverse. Islands are placed, never implemented. Uploads only exist for approved developers, and every version passes human review before it can reach a charity’s site. The agent gets you to a validated artifact fast; the trust chain stays.