Scripting and automation

Using an AI assistant

A generative AI tool can write and revise pages, settings and scripts quickly. HotDog's drafts, checks and reviews keep that safe, on one site or many.

Your whole site is plain text in a folder: the kind of thing AI writing and coding assistants work with best. Point one at your site's folder and it can draft pages, rewrite text, fix what the checks find, restyle sections, or write the scripts in Many sites at once.

What makes it safe isn't trust in the assistant. It's that HotDog never lets a change reach your visitors without being on a draft, built, checked and reviewed. An assistant works inside the same rules as everyone else.

Choosing an assistant

Any assistant that can read and write files in a folder will do: one built into your code editor, one in your terminal, or a chat tool you paste text into.

  • Prefer one that runs on your own computer where you can. Your drafts, and anything private in your site's folder, stay with you.
  • If you use one run by another company, remember that whatever it reads is sent to them. Don't let it read anything you wouldn't send: keep secrets out of your site's folder (HotDog never needs them there).

The safe way to work

  1. Start a branch. Never let an assistant work on the branch your site publishes from:

    git switch -c ai/summer-menu
    
  2. Tell it what you want, and what it may touch. For example: "In content/, write a page called Summer menu from these notes. Keep the tone of the other pages. Don't change anything in layouts/, site.yaml or publish.yaml."

  3. Run the checks, or ask it to:

    hotdog-cms check -fix
    

    The -fix hints tell the assistant (and you) exactly what to change. Let it fix the findings, and check again until there are no errors.

  4. Look at it. hotdog-cms serve, and read the page in your browser. Read what it wrote: assistants can sound sure of things that aren't true, like opening hours or prices.

  5. Read the change itself:

    git diff
    

    Every line it added or removed is there. Nothing it did is hidden.

  6. Commit, push and review, as with any change. Your pipeline checks it again; a preview shows it to anyone reviewing.

Revising quickly

This is where an assistant and HotDog work well together:

  • Try several versions. Make a branch for each ("ai/menu-short", "ai/menu-friendly"), let the assistant write each, and compare them side by side in previews. Merge the one you like; delete the others.
  • Undo is always one step. Every change is a commit; git revert takes it back, and the history says what happened.
  • Let it fix what the checks find. Paste the output of hotdog-cms check -fix, or let it run the command itself: missing descriptions, summaries too long, pictures without alt text.

Helping it understand your site

  • llms.txt. With outputs: { llms: true } in site.yaml (the template has it on), every build writes /llms.txt: a plain list of your site's pages and what each is about, which AI tools read to understand a site quickly. Point your assistant at public/llms.txt.
  • These docs. Give it the pages it needs, such as Pages and articles, Sections or the front matter reference, so it writes front matter HotDog understands.

Many sites at once

An assistant can make one change across every site in a folder, or write the script that does. Ask for the same shape as Many sites at once: a branch per site, only the sites that need it, hotdog-cms check on each, and no publishing. Then run check-all.sh yourself, look at a few previews, and review each site's change before merging.

Guard rails HotDog gives you

  • The checks can't be skipped. A site with errors isn't published by any route, however it was changed.
  • Words that must never be published can be listed in check.forbid: the name of an internal server, a private address, a draft codename. If an assistant puts one in a page, the checks refuse it.
  • No code in packs, and templates can't reach the network or read outside the site, so a template an assistant writes can't do more than show your content.
  • Publishing needs a person, if you set your platform up that way: require an approval on the publishing branch, and never give an assistant your platform's publishing rights or server keys.