Chat-edited website
A website its staff update by asking ChatGPT
A content workflow for Mulberry Marketing Communications in which staff ask Codex in ChatGPT for a change, a guard decides what can merge on its own, and only a named approver can publish.
How it fits together
Inputs
A request in ChatGPT
A staff member asks Codex in their own ChatGPT workspace, which is connected to the site's repository.
- Codex
Repository instructions
Codex follows the repository's written rules: edit Markdown content and images only, then open a pull request.
Engine
Content guard
Runs from the base branch, so a pull request cannot change the rules that judge it.
- GitHub Actions
Validate the content
Continuous integration checks every change before anything merges.
Merge or hold
Content-only changes from listed editors merge on their own. Anything else is labeled for a person to review.
Deploy to staging
Every merge rebuilds the staging site, so the requester sees the result within minutes.
Next.js
Outputs
Approver release
A listed approver runs the release, which publishes exactly what staging last deployed.
Rollback
A separate approver-only workflow puts the previous release back.
Guardrails
- Every change is a pull request under the requester's own account
- Changes outside content never merge without review
- Merging alone never publishes
The problem
Mulberry wanted its staff to update the new site themselves, without a content management system and without risking the live site. A chat assistant can make the edit, but on its own it has no limits on what it touches or when the change goes public.
What I built
- Repository instructions that keep Codex to content and images and make every edit a pull request.
- A content guard and validator in GitHub Actions that auto-merge content-only changes from listed editors and label everything else for review.
- Automatic deploys to staging on every merge, and a manual release, limited to listed approvers, that publishes exactly what staging serves.
- A rollback workflow, also limited to approvers, that restores the previous release by adding a commit rather than rewriting history.
How I built it
I proved the whole path on a pilot repository first: a Codex request opened a pull request, the guard merged it, staging served it within minutes, and a release and a rollback both worked, while a pull request that tried to change the guard was blocked. The new Next.js site now runs on staging with the same workflow and is in review before launch.
What it shows
I give AI tools real write access only inside rules they cannot change, with a person deciding what goes public.