A repeatable agent workflow across two sites

Project overview

Two sites with almost nothing in common run on the same workflow. One is a long-running personal content library of more than 350 articles, where the work is incremental: new pieces, metadata corrections, structural fixes to a codebase that already exists and cannot break. The other is a marketing site built for a coaching client, where the work was a new build against a brief.

Different problems, one operating pattern. This case study describes the pattern rather than the sites, and client and business identities are left out.

Which agents

The coding agents are Codex and Claude Code. Both sites have been worked on with each, and the workflow is deliberately written so that it does not depend on which one is at the keyboard: the brief lives in the repository, the standards are enforced by the build, and the change arrives as a pull request for review either way.

That portability is the point. An agent is a tool I direct, not a dependency I have built a process around, and a workflow that only functions with one vendor is a workflow with an expiration date.

Repeatable skills, committed to the repository

The instructions an agent needs do not live in a chat window. They are files in the repository, versioned with the code they apply to, so the same task starts from the same brief every time and improvements to that brief persist.

In practice these cover the recurring work: drafting an article to a defined structure, holding a house writing tone across pieces written months apart, auditing a site for customer clarity and conversion, and running an accessibility pass with explicit boundaries around what a tool can and cannot confirm.

The advantage is not speed on any single task. It is that the tenth article and the first one are held to the same brief, and that when I find a gap in the brief, I fix it once in the file rather than remembering to mention it every time.

Standards the build enforces

Two content standards are not left to discipline, because discipline is what fails at article 300. They are encoded in the content schema, and the build fails when they are missing.

Alt text is required on every image. Not recommended. Required. An entry that carries an image and no description will not build, which means the failure surfaces on my machine in seconds instead of shipping silently to somebody using a screen reader.

Every entry carries a description. It does double duty as the meta description and the on-page excerpt, so an entry cannot be published without someone having decided how it is summarized for search results and for readers scanning a list.

Writing these into the schema changes who catches the omission. Not the reviewer, on a good day, but the build, every time.

Review before merge

Agents draft and implement. I decide what publishes.

Every change goes onto its own branch and through a pull request that states what changed and why, so the reasoning survives in the history rather than in my memory. Before merge I check the work in a local preview, at desktop and at phone width, because layout problems are invisible in a diff. On a recent change to the client site, a preview at phone width was the only thing that surfaced navigation that had been hidden with nothing to replace it, which the code review had passed over without comment.

I read every draft against the source. I remove claims that are not supported, details that were plausibly invented, and language that does not fit the voice. Where a fact cannot be confirmed, it comes out rather than getting softened.

What this demonstrates

The value is not that an agent can write a page. It is that a repeatable process produces work at a consistent standard across hundreds of entries and more than one site, with the standards written down, the enforcement automated, and the publishing decision held by a person who read the thing first.