A branch, a pull request, a checked image

A website with Codex

Codex takes a task, works on it in a separate branch and opens a pull request. With HERON it can do two jobs: write the content of your pages, or build the site and make sure it passes every check. You review the pull request, and nothing goes live until you merge it.

GitHub builds the site again on its side and checks that it opens, so you merge a change that is already tested.

Set up

1
Put the site in a GitHub repository

Any site folder made with heron new.
Publish with git push
2
Connect the repository to Codex

Codex reads the HERON skills like any project instructions.
3
Add the HERON skills

npx skills add FMSTM/HERON in the repository, then commit the result.
About the skills
4
Check the workflow file

.github/workflows/image.yml builds and checks the site on every push. The configurator writes it when you choose GitHub with the automatic build on.
Configurator

Copy a task

Content

New pages, translations, texts.

This is a HERON site. Use the heron-content skill.
Task: [add a prices page in English and Russian].
Work only in content/, media/ and data/. Copy a page of the same kind for the new page, fill title, h1 and description.
Make heron build . --env prod --strict pass, then open a pull request: what changed, facts you need from me.

You get: A pull request with the new files and a list of missing facts.
Review: On GitHub, the Files changed tab shows every line the agent changed, in red and green.
Accept: When the check is green and the text is right, press Merge: the site updates.
Change something: Write a comment in the pull request; Codex can take it into the next round.

Builder

When the build fails or the site needs a release.

This is a HERON site. Use the heron-builder skill.
Task: [make the strict build pass after the last changes].
Fix errors in the files of the role they belong to and keep within that role's limits. Do not change HERON itself.
Open a pull request with a report: what was wrong, what changed, warnings left.

You get: A green check on GitHub and a report.
The report: What was done, which warnings are left and why, which content is still missing.
When to use: Before a launch, after a HERON update, or when a build fails and you do not know why.

What happens after the pull request

1
GitHub builds the site

The workflow runs the strict build with the stable HERON image.
2
GitHub packs the image

The dist/ folder goes into a small nginx image, made by the recipe of the same HERON version.
3
GitHub checks the image

It starts the image and checks the answers: the home page opens, a missing page gives 404, every redirect gives 301 or 410.
4
You merge

The new image is published to ghcr.io/you/my-site, and your server can take it.
How the update reaches the server

The workflow file

The whole build and check is one short file in the site repository. HERON keeps the long part on its side, so you do not maintain it.

name: image
on:
  push:
    branches: [main]
jobs:
  image:
    uses: FMSTM/HERON/.github/workflows/site-image.yml@prod
    permissions:
      contents: read
      packages: write
    with:
      env: prod
      engine: prod

env

dev builds a closed preview, prod opens the site to search engines.

engine

The HERON version: prod is the stable one.

Questions

Does Codex need access to my server?

No. Codex works with the repository. The server gets the new image from the registry.

Can Codex change the design?

Not in these roles. The theme is a separate task for the designer role: A theme with Claude Design.

What if the check fails on GitHub?

The pull request shows a red mark and the log names the page and the error. Ask Codex to fix it in the same branch.

A website with Codex

Set up

Put the site in a GitHub repository

Connect the repository to Codex

Add the HERON skills

Check the workflow file