I wanted to redesign my website and explore how far I could get with an AI agent. For me, it was an experiment with a serious goal: the result should not be a demo, but a website I could actually use and continue to develop.
I decided against a website builder and a content management system. Instead, I wanted a manageable website made of its own files. I also wanted to show that a simple website can be built without those tools, with help from Hermes Agent.
An experiment with a real result
Before the rebuild, cloasdata.de ran on WordPress. For the new version, I chose a static website: the pages consist of HTML and CSS, with JavaScript where needed. A CMS is not required to serve the new pages.
At first, that sounds like more manual work. A CMS lets you edit text in an interface and use extensions for many tasks. On a static site, design and content are stored in files instead. That keeps the site manageable, but changes and publication need a suitable workflow.
This was where I wanted to test Hermes Agent. The agent was not just supposed to suggest a piece of code for me to put together afterwards. The task covered the design of the website, its technical implementation and work on its content.
My role was to set the direction, make decisions and assess the results. Hermes assisted with developing and implementing the ideas. The website did not come together at the press of a button, but through several steps and an ongoing exchange.
From project work to a skill
Working on a website brings up recurring questions: Where are the files? How is an article structured? Which language versions need to be updated? And what needs checking before changes go online?
If that information is buried in a long chat, the next task becomes unnecessarily difficult. That is why a dedicated Hermes skill emerged for work on cloasdata.de.
Here, a skill is a collection of instructions and project knowledge that Hermes can draw on for relevant tasks. The cloasdata-redaktion skill describes, for example, how articles on this website are structured, what to consider for German and English versions, and which checks come before publication.
It also records safety boundaries: changes to the live website should not happen casually. Before an upload, the exact scope needs to be agreed and existing files backed up.
The skill does not replace human decisions. It helps make sure that important steps do not have to be rediscovered for every new task.
What I want to show
For me, the website is also a practical example of what an AI agent can help accomplish. Someone who wants to run a simple website does not automatically need to choose a website builder. An agent can help develop design ideas, create files and make technical tasks easier to understand.
That does not mean every website can be built reliably without expertise or oversight. An agent can make mistakes, misrepresent content or suggest changes in the wrong place. Privacy, security and publication deserve particular attention. A CMS may still be the better choice for more complex requirements.
For cloasdata.de, the rebuild was an opportunity to try this way of working on a real project. The resulting skill makes some of that experience useful for later work. An abstracted version is available below under the MIT licence, so others can use it as a starting point for their own websites and adapt it.
Read and download the skill
This is the abstracted English-language version. It contains no project-specific credentials or local paths. The instructions are a starting point and need adapting to your own project. The MIT licence permits reuse; retain the licence and copyright notice.
Download SKILL.md · Download the MIT licence
---
name: editorial-workflow
description: Use when researching, editing, reviewing, or preparing website articles for publication.
license: MIT
metadata:
hermes:
tags: [editorial, research, accessibility, publishing]
---
# Editorial workflow
## Scope
Use this workflow for website articles and their supporting assets. Follow the user's language and project conventions. A topic or source is not a publication authorization. Ask only for information that is necessary and cannot be established from available sources.
## Research and writing
1. Read the relevant existing content, project instructions, and source material before editing. Establish the intended audience and scope. For repository-based claims, inspect the relevant files and record the reviewed revision where possible.
2. Prefer primary sources. Distinguish documented features, available tests, and tests actually run. Do not invent facts, quotes, benchmarks, experiences, or results. Label uncertainty, historical status, and untested commands clearly.
3. Match the publication's voice and design without copying protected artwork. Explain the practical purpose first and include relevant limitations. For multilingual projects, prepare complete requested language versions and check corresponding navigation and language links.
4. Use only media with suitable rights. Record provenance, applicable license or generation method, and any attribution requirements in the project's designated records. Consider privacy before using external services.
## Local preparation and review
1. Inspect build scripts and their dependencies before execution, including import-time side effects and files they may overwrite. Preserve existing work and use a separate output location when appropriate. Do not assume an old build represents the current site.
2. Check changed pages, assets, links, anchors, language navigation, and responsive layout. In a browser, inspect desktop and mobile views, image loading, contrast, keyboard focus, and code blocks. Serve locally over HTTP where browser security rules make file URLs unreliable.
3. Report precisely what was reviewed or executed and what remains untested. Raise unresolved factual, rights, accessibility, or editorial issues before publication.
## Publication boundary
- Finish and review locally first. Explicit approval of text alone is not approval to upload, overwrite, delete, change routing, or modify hosting configuration. Obtain approval for the exact target and scope of each live change.
- Before an approved deployment, verify the current target and affected live state; prepare and check a protected backup and a rollback path. Do not expose backups or credentials. Use only an approved secure transfer method; do not request or handle passwords in chat.
- Deploy only the approved files. Afterward, verify the exact deployed files and relevant live pages, navigation, and redirects. Report any failures and use the agreed rollback procedure when necessary.
## Optional delegation
Delegate independent research or isolated reviews only when useful. Give each reviewer a bounded task and prohibit remote writes, publication, and access to secrets. These instructions are not a technical sandbox. Independently check sources, findings, and claimed tests; keep approval and deployment coordination with the main agent.