Setting up a Hermes agent for your website

I started this site-management project with a simple goal: make the website easier to improve without turning every small change into a full engineering project. A personal website has a lot of small moving parts — copy, navigation, articles, images, SEO, GitHub, Vercel, and the occasional dependency warning — and it is easy for those details to drift.

Hermes is useful here because it can work across the whole loop. It can inspect the repository, run the development server, check the live site in a browser, write down a plan, keep tasks on a Kanban board, run lint and build checks, and prepare changes for GitHub/Vercel.

What the agent needs first

Before an agent can safely manage a website, it needs a clear working environment:

  1. Access to the repository on the local filesystem.
  2. A reliable way to run the site locally.
  3. A known deployment path, usually GitHub pushing to Vercel.
  4. A project map that explains where content, components, and routes live.
  5. A lightweight planning system so improvements happen incrementally.

For this site, the important commands are intentionally boring:

npm install
npm run dev
npm run lint
npm run build

The important path is the active Next.js project:

Desktop/website/personal_professional_website

Start with assessment, not edits

The first useful agent task was not to change code. It was to look around and answer a few questions:

  • Does the site build?
  • Which directory is the real project, and which directories are templates or archives?
  • What content is real, and what content came from the starter template?
  • Are GitHub and Vercel set up in a way that makes pushes safe?
  • Are there lint, build, or dependency issues that would surprise us later?

That assessment turned into a small backlog instead of one big rewrite.

Use a Kanban board for small improvements

A shared board makes the work easier to reason about. The first cards were deliberately small:

  • stabilize repo hygiene
  • fix linting so CI can run non-interactively
  • add GitHub Actions CI
  • decide public navigation
  • replace template content
  • centralize editable site content

That is the right shape for website work. Each card should leave the site in a better state, with npm run lint and npm run build passing before anything is committed.

Keep the agent honest with verification

The most important rule is that the agent should not just say something is fixed. It should run the checks.

For this website, the minimum verification loop is:

npm run lint
npm run build

For visual changes, the agent should also run the dev server and inspect the relevant page in a browser. If the local server returns a 500, that matters even if the production build passes. The local feedback loop should be healthy before pushing.

Make content easier to edit

Template sites often start with content embedded directly in React page files. That is fine at first, but it becomes harder to maintain as the site grows. A better pattern is to move stable facts into small content modules, for example:

src/content/site.ts
src/content/work.ts

That lets the page components focus on rendering while the editable site facts live in one place.

The workflow I want

The ideal workflow for this site is straightforward:

  1. Pick one Kanban card.
  2. Make the smallest useful change.
  3. Run lint and build.
  4. Preview locally.
  5. Commit on a branch.
  6. Push to GitHub.
  7. Let Vercel build and deploy.
  8. Verify production.

That gives the site a rhythm: small changes, real checks, clear history, and no mystery deployments.

This article is a placeholder, but it captures the direction. The website should not just be a portfolio; it should also become a well-managed project that is easy to update over time.