Part 2: Shipping the Article — How Hermes Turns a Brief Into a Live Page

The first article in this series was about conversation: I brief Hermy in Discord, talk through the angle, and turn a messy idea into something usable. This article is the middle piece — the technical publishing rig that takes that brief and turns it into a real article on the site.

That matters because the useful bit is not just that Hermy can write. The useful bit is that Hermy can work against the actual Bloomindesign project files sitting on the machine, change the repo, run the checks that matter, inspect the result in Chrome, push the update to GitHub, let Vercel deploy it, and then verify that the thing is genuinely live instead of merely sounding finished in chat.

Why this needs its own article

It is easy to imagine that the workflow stops once the brief becomes a draft. It does not. There is a whole second layer where the article has to become code: content objects get updated, images get placed, links get added, layout tweaks happen when needed, and the final result has to survive build and deployment.

That second layer is what makes Hermy feel less like a chat toy and more like a working editorial assistant. The brief does not just become words on a screen. It becomes a commit.

What the development cycle actually includes

Step 1: Step 1: The brief arrives in Discord

Everything still starts in conversation. I explain the article, the angle, the purpose, and any details I care about. Because it is chat, I can be vague first and precise later. I can ramble, correct myself, or add a new section halfway through. Hermy turns that into a usable brief rather than expecting me to behave like a project-management robot.

This part matters because the development cycle inherits whatever clarity comes out of the conversation. If the brief sharpens, the implementation sharpens with it.

Step 2: Step 2: The brief becomes real files on Hermy's machine

Once the brief is clear enough, Hermy stops treating it like pure conversation and starts treating it like implementation work. In the Bloomindesign setup that usually means updating lib/posts.ts, placing or replacing assets in public/images/blog/, and occasionally touching supporting files when the article needs a more bespoke layout.

That is the practical difference between “an AI helped me write something” and “an AI helped me publish something.” The article becomes a set of controlled repo changes, not a blob of text copied around by hand.

Step 3: Step 3: Chrome is where the article gets checked properly

Chrome is useful here because the truth of an article is visual as well as textual. A paragraph can look fine in a file and still feel wrong on the page. A workflow block can compile and still be ugly. A banner can technically exist and still look naff once it lands in the actual layout.

So Hermy uses Chrome as the eyes of the workflow: inspect the page, check the layout, look at the article in context, confirm links behave properly, and make sure the live output matches what the repo changes were supposed to produce. That closes the gap between implementation and reality.

Step 4: Step 4: Validation runs before the push

For Bloomindesign, the reliable hard gate is the production build. bun run build runs the Next build and TypeScript pass, which tells me whether the article route generates cleanly and whether the site still compiles as a whole.

There is also a lint script in the repo, but right now it resolves badly under this setup and exits with an invalid project-directory error. Hermy should surface that honestly rather than waving a magic wand and declaring lint successful because it sounds nicer in a status update.

bun run build
# if useful, also check the current repo state
git status --short
git diff --stat

Step 5: Step 5: Images get optimised before they become part of the site

Image generation is not the end of the visual workflow. Before assets go live, Hermy should optimise them for the web. In practice that means converting heavy source PNGs into lighter WebP assets when appropriate, checking file sizes, and updating article references so the site serves the leaner versions instead of hauling around giant originals for no good reason.

That sounds boring because it is boring. It is also exactly the kind of boring detail that makes the whole system more professional. A banner should look good and load sensibly; it should not arrive at the page like a seven-megabyte brick through the window.

Step 6: Step 6: GitHub and Vercel take it the rest of the way

Once the article changes and assets are in place, Hermy commits them, pushes to GitHub, and lets Vercel pick up the new state of the repo. From there the workflow becomes deployment and verification: wait for the site to rebuild, check the article route, and make sure the production page is serving the new content rather than some older cached version.

That final verification matters. A 200 status code on its own is not enough. Hermy should also check for expected text or the updated asset itself so there is evidence the new version is the one actually being served.

The model in the middle of the process

For this series, the drafting and orchestration layer has used Codex as the model doing the work. That is an implementation detail in one sense, but it is also part of the workflow design: Hermy can coordinate the repo, browser, file, and deployment steps while the chosen model handles the writing and transformation work in the middle.

The useful pattern is not blind loyalty to one model. The useful pattern is that the system remains stable even if the model changes. The workflow should still know how to take a brief, touch the right files, run the checks, optimise the assets, and verify the live result.

Read the full series

Three articles, one system: conversation, development cycle, then image workflow.