Build an AI DevOps Engineer

Introduction

30 Second Summary

In any engineering team, there is always someone who checks that config files, build scripts, and deployment manifests actually work before they hit production. That person catches the typo that would have caused an outage at 2am.

In this project, you will promote your Hermes AI agent to a DevOps Engineer that audits your repository, containerizes your application, builds a CI/CD pipeline, and validates every artifact it generates before committing.

What You'll Build

Your AI DevOps Engineer will push a CI workflow to GitHub, watch the run complete, read the logs itself, and fix any failures it finds. You will point at the resulting repository and say: my AI agent prepared this for production and proved every piece of config is correct.

By the end of this project, you'll have:

• A deployment readiness audit tailored to your specific scaffold, identifying exactly what is missing for production.
• Validated Docker configuration and Kubernetes manifests checked by real linting tools without running a single container or cluster.
• A real green checkmark on a GitHub Actions run that your AI agent triggered, monitored, and diagnosed entirely on its own.
• Secret Mission: Kick off Continuous Delivery by wiring up automated CI checks for every future code change.

Are there any prerequisites?

This is Part 4 of the Hermes series. You need Parts 1-3 completed (or fork the provided TaskFlow starter template). You should already have Hermes Agent installed with the GitHub MCP server configured, and a GitHub repository with the Part 3 scaffold.

Before We Start

Before diving in, let's commit to what you're building and why it matters. A DevOps Engineer never hands over untested config, and neither will your AI agent.

Promote Hermes to DevOps Engineer

In Parts 1-3, Hermes generated code and documentation as a Software Engineer. Now it needs a completely different identity for the next job: preparing your repository for production deployment.

A DevOps Engineer's first rule is "never commit untested config." In this step, you'll create a DevOps Engineer persona that bakes validation into every task Hermes performs. This persona file lives in your repository so Hermes picks it up as project context every session.

In this step, get ready to:

• Create a DevOps Engineer persona file defining Hermes's deployment responsibilities.
• Verify Hermes understands its new role and can explain its deployment preparation plan.

Have the Engineering Manager delegate deployment preparation

Just like a real engineering manager defines a role before assigning it, you'll ask Hermes (in its Engineering Manager persona from Part 3) to create the DevOps Engineer role definition. This file tells Hermes exactly what it's responsible for when operating as the DevOps Engineer.

• In your Hermes Agent session, paste the following prompt to have the Engineering Manager create the persona file:

As Engineering Manager, I need you to delegate deployment preparation to a new specialist: the DevOps Engineer. Create a file called DEVOPS-ENGINEER.md in the root of our repository that defines this role.

The DevOps Engineer's responsibilities are:
1. Audit the existing scaffold for deployment readiness
2. Containerize the application with Docker
3. Automate builds via CI/CD with GitHub Actions
4. Create Kubernetes deployment manifests
5. Validate every artifact before committing it to the repository

The key principle for this role: never commit untested configuration. Every generated file must be validated with the appropriate tool before it touches the repository.

Commit DEVOPS-ENGINEER.md to the main branch of the repository.

What does this prompt do?

This prompt asks Hermes (acting as the Engineering Manager) to create a persona definition file in your repository. The file serves two purposes.

• It gives Hermes a clear identity and scope when you ask it to act as the DevOps Engineer in later steps.
• It encodes the validation-first principle so Hermes knows to check its work before every commit.
• Hermes will use the GitHub MCP tools (like create_or_update_file) to commit DEVOPS-ENGINEER.md directly to your repository.

Hermes will read your repository structure, compose the persona file, and commit it. You should see Hermes confirm the commit in its response.

• Confirm the file exists by checking your repository on GitHub. Navigate to your repository's main page and look for DEVOPS-ENGINEER.md in the file list at the root level.

Don't see the file in your repository?

• Check Hermes's output for any error messages. If it mentions permission issues, confirm your GitHub PAT has the repo scope enabled.
• Make sure Hermes committed to the correct branch. Ask Hermes: "Which branch did you commit to?" and verify it matches your default branch.
• If Hermes created the file locally instead of pushing to GitHub, remind it to use the GitHub MCP tools to commit directly to the remote repository.

Still stuck? Help me troubleshoot why Hermes didn't commit DEVOPS-ENGINEER.md to my GitHub repository.

Test the new DevOps Engineer persona

The persona file is committed. Now you need to confirm Hermes can actually adopt the role and understands what it's supposed to do.

Before you ask Hermes to explain its plan, think about what you expect it to mention. What are the five responsibilities you defined in the persona file?

• Paste this prompt into Hermes to test the promotion:

You are now the DevOps Engineer defined in DEVOPS-ENGINEER.md. Read that file from the repository, adopt that role, and explain what you will do to prepare this repository for deployment. Reference the specific responsibilities and the validation principle from your persona file.

What should I see?

Hermes should identify itself as the DevOps Engineer and outline a plan that covers all five responsibilities from the persona file:

• Auditing the existing scaffold for deployment gaps.
• Containerizing the application with Docker.
• Setting up CI/CD with GitHub Actions.
• Creating Kubernetes deployment manifests.
• Validating every artifact before committing.

If Hermes doesn't reference the validation principle, ask it again with emphasis: "What is your key principle before committing any file?"

Hermes not adopting the DevOps Engineer role?

• Hermes may not have read DEVOPS-ENGINEER.md from the repository. Try explicitly asking: "Read the file DEVOPS-ENGINEER.md from the repository and adopt that persona."
• If Hermes responds generically without referencing specific responsibilities, start a fresh session with /new and re-run the prompt. A fresh session forces Hermes to reload project context.

Need more help? Hermes is not adopting the DevOps Engineer persona from DEVOPS-ENGINEER.md.

Hermes is now operating as your DevOps Engineer with a clear mandate: audit, containerize, automate, deploy, and validate everything. Next up, it will put that mandate to work by auditing your actual scaffold and identifying exactly what's missing for production.

Run a Deployment Readiness Review

Hermes is now operating as your DevOps Engineer. Before it starts generating deployment files, it needs to understand what it's working with.

Every Part 3 scaffold is different because it was AI-generated. Hermes cannot assume a fixed project structure. It must inspect your actual repository to identify what exists and what's missing before it can build anything on top.

In this step, get ready to:

• Have Hermes audit your existing scaffold structure, dependencies, and configuration.
• Generate a deployment readiness checklist specific to your repository.
• Commit and review the checklist to confirm it reflects your actual project.

Audit the existing scaffold

A real DevOps Engineer always starts with a gap analysis. They review the current state of a codebase before making changes so they know exactly what needs to be added.

Your Part 3 scaffold was generated by AI, which means its file structure, dependencies, and configuration are unique to you. Hermes needs to inspect what actually exists rather than assuming a template.

• In your Hermes session, ask the DevOps Engineer to audit your repository by entering this prompt:

Audit our repository for deployment readiness. Inspect the project structure, package files, dependencies, configuration files, environment variables, and any existing Docker or deployment artifacts. Report back what you find before making any changes.

What does this prompt do?

This instructs Hermes to read through the repository using the GitHub MCP tools and catalog what it finds. Because it has the DevOps Engineer persona loaded, it knows to look specifically for deployment-related artifacts.

Hermes will use tools like get_file_contents and directory listing to inspect your repository structure. You will see tool calls streaming in the activity feed as it reads files.

Hermes will output a summary of what it found in your scaffold. This includes your project's file tree, the package manager and dependencies it detected, any scripts defined, and whether any deployment artifacts already exist.

Every scaffold looks different

Your audit output will not match anyone else's. That is expected. The whole point of this step is that Hermes adapts to YOUR repository rather than following a generic template.

Hermes not reading your repository?

Make sure you are in the same Hermes session where the DevOps Engineer persona was loaded. If you started a new session, the persona context is lost. Resume the previous session or re-load the persona.

Confirm that the GitHub MCP server is connected by checking the tool activity feed. If no GitHub tools appear, restart Hermes with the GitHub MCP configuration from Step 1.

Help me troubleshoot why Hermes cannot read my GitHub repository.

Generate the deployment checklist

Now that Hermes has a picture of your scaffold, it can identify the gaps. A deployment checklist turns that audit into a structured action plan.

• Ask Hermes to create the checklist by entering this prompt:

Based on your audit, create a file called DEPLOYMENT-CHECKLIST.md in the repository root. It should document three sections: (1) What Exists - the structure, dependencies, and scripts you found, (2) What Is Missing - gaps for deployment including Docker support, CI/CD pipeline, Kubernetes manifests, and operations documentation, (3) Prioritized Action Plan - ordered steps to close each gap. Reference specific files and directories you inspected.

Why reference specific files?

Requiring Hermes to reference specific files proves the checklist came from an actual inspection of your scaffold. A generic checklist would say "add Docker support" without naming anything specific. Your checklist should mention files it actually found, like your package.json or requirements.txt or whichever dependency file exists in your scaffold.

Hermes will use the GitHub MCP to create DEPLOYMENT-CHECKLIST.md directly in your repository. Watch the activity feed for the file creation tool call.

Hermes creating a generic checklist?

If the checklist looks like a generic template without references to your specific files, interrupt Hermes and clarify. Tell it to re-read the repository and cite actual file names and directory paths it inspected.

Help me get Hermes to produce a scaffold-specific deployment checklist.

Commit and review the checklist

Hermes should have committed the file as part of the creation step. Now you need to verify it landed in your repository and that the content accurately reflects your scaffold.

• Ask Hermes to confirm the commit by entering this prompt:

Confirm that DEPLOYMENT-CHECKLIST.md has been committed to the repository. Show me the commit details.

Hermes will report the commit SHA and confirm the file is in the repository root.

• Open your GitHub repository in a browser.
• Navigate to the repository root.
• Confirm that DEPLOYMENT-CHECKLIST.md appears in the file list.
• Click the file to open it and read through the contents.

Before you move on, think about this: does the checklist reference files and directories that actually exist in YOUR scaffold? Or does it read like a generic deployment guide?

• Verify that the "What Exists" section names real files from your repository (your actual dependency file, your actual source directory, your actual scripts).
• Verify that the "What Is Missing" section identifies Docker support, a CI/CD pipeline, Kubernetes manifests, and operations documentation as gaps.

What makes this checklist good?

A good deployment checklist is specific to the project it describes. It names the dependency manager it found, the scripts that already exist, the directories it inspected. The gaps it identifies are not guesses. They are conclusions drawn from the absence of specific artifacts after a real inspection.

This is the difference between an AI that generates from templates and one that adapts to context. Hermes assessed your unique scaffold and produced a plan tailored to it.

Checklist not in your repository?

If the file is not visible on GitHub, Hermes may have created it locally but not pushed. Ask Hermes to commit and push the file explicitly. Confirm that the GitHub MCP's create_or_update_file tool was used, which commits directly to the remote repository.

Help me figure out why my DEPLOYMENT-CHECKLIST.md is not showing up on GitHub.

Your DevOps Engineer now has a clear picture of the terrain. It knows what your scaffold contains and exactly what needs to be added. Next up, Hermes will tackle the first gap on that list: containerizing your application and validating the result before committing.

Containerize and Self-Validate

In the previous step, Hermes audited your scaffold and documented every deployment gap in DEPLOYMENT-CHECKLIST.md. The first gap on that list is Docker support. Without containerization, your application has no portable way to run in production.

Generating Docker files is straightforward for an AI agent. The harder skill is verifying those files actually work before committing them. This step introduces the project's core pattern: the generate-then-verify loop. Hermes creates config, validates it with real tools, fixes any issues it finds, and only commits once everything passes.

In this step, get ready to:

• Generate Docker configuration files tailored to your scaffold's tech stack.
• Validate the Dockerfile and docker-compose.yml with real linting tools.
• Commit only after validation confirms zero issues.

Generate Docker configuration files

Your scaffold needs three files to be container-ready: a Dockerfile that defines how the app gets built into an image, a docker-compose.yml that wires up the services, and a .dockerignore that keeps unnecessary files out of the build context.

• Ask Hermes (as the DevOps Engineer) to generate all three Docker files by giving it this prompt:

Based on the scaffold you audited in DEPLOYMENT-CHECKLIST.md, generate three files:

1. A minimal, production-appropriate Dockerfile for this project's tech stack
2. A docker-compose.yml defining services based on the architecture
3. A .dockerignore that excludes irrelevant files from the build context

Do NOT commit these files yet. Create them locally so we can validate them first.

What do these three files do?

• Dockerfile is a recipe for building the application into a container image. It specifies the base image, copies source files, installs dependencies, and defines the startup command.
• docker-compose.yml defines how services relate to each other (web server, database, cache) and how they connect. It makes multi-container setups reproducible with a single command.
• .dockerignore works like .gitignore but for Docker builds. It prevents large or sensitive files (like node_modules, .git, or .env) from being copied into the image.

• Confirm Hermes created all three files. You should see it write Dockerfile, docker-compose.yml, and .dockerignore to your repository's root directory.

Why are these minimal deployment containers?

Hermes is preparing the scaffold for deployment, not implementing new features. The Dockerfile should use a slim base image, install only production dependencies, and expose the correct port. The docker-compose.yml maps out the services your architecture needs without adding extras.

Hermes trying to commit the files immediately?

If Hermes commits the files before you can validate them, remind it of its persona instructions: validate every artifact before committing. You can say: "Do not commit yet. We need to validate these files first."

help me stop Hermes from committing files before validation

Validate the Docker configuration

This is the moment where your DevOps Engineer earns its title. A real engineer never commits config without checking it first. Hermes will now run hadolint against the Dockerfile and docker compose config --quiet against the compose file.

• Ask Hermes to validate the Dockerfile by running hadolint in the terminal:

Now validate the Dockerfile by running hadolint against it in the terminal. Report the full output.

If hadolint finds any issues, fix the Dockerfile and re-run hadolint until it passes with zero warnings or errors. Show me each iteration.

What does hadolint check?

hadolint parses your Dockerfile into an abstract syntax tree and checks it against best-practice rules. It also uses ShellCheck to lint any Bash inside RUN instructions.

Common issues it catches include: unpinned package versions in apt-get install, missing --no-install-recommends flags, using cd instead of WORKDIR, and untagged base images.

Before you look at the output, predict: do you think hadolint will find issues on the first pass, or will the Dockerfile pass cleanly?

AI-generated Dockerfiles commonly trigger hadolint warnings on the first run. This is expected and valuable. Watch how Hermes reads the specific rule codes (like DL3008 or DL3015), fixes each issue, and re-validates. That loop is the generate-then-verify pattern in action.

What is the generate-then-verify loop?

In Parts 1-3, Hermes generated artifacts and committed them immediately. The generate-then-verify loop adds a critical step: after creating a file, Hermes runs a validation tool against it. If the tool finds problems, Hermes fixes them and re-runs until the output is clean.

This mirrors how human DevOps engineers work. You never push a Dockerfile without linting it first. The loop catches mistakes before they reach the repository.

• Once hadolint passes (no output, meaning zero violations), ask Hermes to validate the compose file:

Now validate docker-compose.yml. If Docker CLI is available, run:
  docker compose config --quiet

If Docker CLI is not available, perform YAML structure validation and note the fallback.

Report the result.

What does docker compose config --quiet do?

The --quiet flag tells Docker Compose to validate the configuration without printing anything. If the file is valid, the command exits silently with a zero exit code. If there are errors (bad indentation, invalid service keys, unresolved variables), it prints those errors.

This command does not require running containers or even Docker Desktop. It only needs the Docker CLI installed. If even the CLI is unavailable, Hermes falls back to YAML structure validation. This is intentional DevOps behavior: validate with the best tool available on the machine.

• Confirm both validations pass. You should see hadolint produce no output (clean pass) and docker compose config --quiet exit silently or report a successful YAML validation.

Hadolint not found or validation failing repeatedly?

If Hermes reports that hadolint is not found, confirm it is installed and on the system PATH. You installed it in Step 1.

If hadolint keeps finding issues after multiple fix attempts, ask Hermes to show you the specific rule codes it is struggling with. Some rules (like requiring pinned versions for every system package) may need a targeted # hadolint ignore=DLxxxx comment if the fix is not practical for your scaffold.

help me troubleshoot hadolint validation failures

Commit after validation passes

Only now, with proof that both files are correct, does Hermes earn the right to commit.

• Ask Hermes to commit all three Docker files with a message that references validation passing:

Commit all three Docker files (Dockerfile, docker-compose.yml, .dockerignore) to the repository.

The commit message must reference that hadolint and docker compose validation both passed before this commit.

• Confirm Hermes commits the files. The commit message should mention that validation passed. You should see something like "Add Docker configuration (validated with hadolint and docker compose config)" in the commit output.

Why reference validation in the commit message?

In professional DevOps workflows, commit messages that reference validation tell future reviewers: this config was checked before it landed. It is a signal of quality. When someone reads the git log six months from now, they know this Dockerfile was not blindly generated.

Commit failing?

If Hermes reports a push or commit error, check that your GitHub PAT still has the repo scope. The files are in the repository root, so no special permissions beyond what you set up in Step 1 are needed.

help me fix a commit failure in Hermes

Your repository now has validated Docker configuration. No container was run, no image was built, but you have proof that the config is correct. Next up, Hermes will create a CI/CD pipeline, push it to GitHub, and watch it run.

Set Up CI/CD and Watch It Run

Your Docker configuration passes local linting, and your compose file validates cleanly. But local validation only catches syntax errors.

A real CI/CD pipeline proves the entire build works end-to-end on a fresh machine. This is where Hermes closes the generate-then-verify loop by pushing a workflow, watching it run, and reading its own result.

In this step, get ready to:

• Have Hermes create and push a GitHub Actions CI workflow.
• Watch Hermes monitor the run, diagnose failures, and self-correct.
• Confirm a green checkmark on a real pipeline run.

Have Hermes create and push the CI workflow

A GitHub Actions workflow lives in a special directory: .github/workflows/. Pushing a file there requires the workflow scope on your PAT, which you already added in Step 1.

• Give Hermes this prompt:

Create a GitHub Actions CI workflow at .github/workflows/ci.yml.

The workflow should:
- Trigger on push to the main branch
- Run on ubuntu-latest
- Include these steps: checkout the code, install dependencies, run lint, run the build, and add a placeholder deployment step (just an echo saying deployment would happen here)

After creating the file, push it to the repository. The workflow will trigger automatically once pushed.

What is Hermes doing here?

Hermes uses the GitHub MCP's create_or_update_file or push_files tool to commit the workflow file directly to your repository's main branch.

The moment that push lands, GitHub detects the new workflow file and starts a run automatically. You don't need to trigger anything manually.

• Wait for Hermes to confirm it has pushed .github/workflows/ci.yml to the repository.

Hermes says it cannot push to workflows?

This means your PAT is missing the workflow scope. Go to your GitHub PAT settings, edit the token, check the workflow checkbox, and save. Then ask Hermes to try pushing again.

Help me fix my GitHub PAT permissions for pushing workflow files.

Monitor the workflow run

Here is where things get interesting. First CI runs on AI-generated scaffolds commonly fail. Dependency mismatches, missing build scripts, or lint rules the code doesn't satisfy are all typical causes.

Before you ask Hermes to check the run result, think about this: do you expect it to pass or fail on the first try? Why?

• Ask Hermes to monitor the workflow run by giving it this prompt:

Check the status of the CI workflow run that was just triggered. Use the GitHub Actions tools to:
1. List the workflow runs to find the latest one
2. Wait for it to complete (check every 30 seconds if it's still in progress)
3. Once complete, read the job logs
4. Report whether it passed or failed

If it failed, diagnose the issue from the logs, fix the problem, push the fix, and monitor the new run until it passes.

What tools is Hermes using?

Hermes calls actions_list or actions_get to find the workflow run and check its status. Once the run completes, get_job_logs fetches the full log output from the run.

This is the generate-then-verify loop in its most powerful form. Hermes is not just generating config files. It is watching the live result of its own work and responding to failures autonomously.

Watch what happens next in the terminal. If the run failed (which is likely on the first attempt), you should see Hermes read the logs, identify the failing step, explain the root cause, apply a fix, push again, and re-monitor.

Why is a first-run failure a good thing?

This failure is intentional and expected. Your scaffold was generated by AI in Part 3, which means the exact dependencies, lint rules, and build commands are unpredictable. A real DevOps engineer hits this same problem: you write the pipeline, it fails, you read the logs, you fix it.

The difference is that Hermes does the entire diagnosis-and-fix cycle itself. You are watching an AI agent operate the way a human DevOps engineer would. Read → diagnose → fix → verify.

• Let Hermes continue until it reports a successful (green) run. This may take one or more fix-and-retry cycles.

Hermes seems stuck or keeps failing?

If Hermes has attempted three or more fix cycles without success, ask it to show you the exact log output from the latest failing step. Then paste that error back to Hermes with the prompt: "Focus only on fixing this specific error. What exact change is needed?"

My Hermes Agent keeps failing CI runs in a loop. Help me break out of this cycle.

Confirm the green run

Once Hermes reports success, it should provide the run details: run ID, duration, and status. This is your proof that the pipeline works end-to-end.

• If Hermes did not already provide run details, ask it:

Report the details of the successful CI run: run ID, how long it took, and the final status of each job step.

• Open your repository on GitHub in your browser.
• Click the Actions tab at the top of the repository page.

You should see at least one workflow run with a green checkmark. If Hermes had to fix failures along the way, you may also see earlier runs marked with a red X. That is expected. The most recent run should be green.

What does the green checkmark prove?

The green checkmark means your code checked out on a fresh Ubuntu machine, installed all dependencies from scratch, passed linting, and built successfully. That is a stronger guarantee than any local test.

Hermes triggered this run, monitored it, read the result, and fixed it if needed. All without you touching the GitHub UI or reading logs manually.

GitHub Actions free tier

Free GitHub accounts get 2,000 minutes per month for Actions runs. The 2-3 runs this project triggers are negligible. No cost concerns here.

Your pipeline is green. That green checkmark is proof that your AI agent can not only generate deployment config, but verify it works in production conditions. Next up, Hermes tackles Kubernetes manifests and operations documentation to finish preparing the repository for production.

Create Kubernetes Manifests and Operations Docs

Your CI pipeline has a green checkmark. The application builds and tests successfully in the cloud.

Now the team needs deployment targets. Kubernetes manifests tell a cluster how to run and expose your application, but manifests without validation are a production incident waiting to happen. In this step, Hermes creates manifests, proves they are schema-valid, and writes the operations documentation a human would need to deploy and roll back.

In this step, get ready to:

• Generate Kubernetes deployment and service manifests for the application.
• Validate manifests against real schemas using kubeconform.
• Create deployment and rollback documentation referencing actual repository files.

Generate Kubernetes manifests

Kubernetes needs two core resources to run your application: a Deployment (which manages the containers) and a Service (which exposes them to network traffic). Hermes will generate both and explain what each one does.

• Ask Hermes to create Kubernetes manifests by giving it this prompt:

Create Kubernetes manifests for our application. Generate two files:

1. k8s/deployment.yaml - A Deployment that references the Docker image from our Dockerfile, configures appropriate CPU and memory resource requests/limits, and sets up health checks.

2. k8s/service.yaml - A Service that exposes the application to network traffic.

Explain what each manifest does and how they work together. Do NOT commit yet - I want to validate them first.

What should Hermes produce?

Hermes should create a k8s/ directory containing two YAML files. The deployment.yaml defines how many replicas to run, which container image to pull, and what resources to allocate. The service.yaml creates a stable network endpoint that routes traffic to those containers.

Hermes should also provide an explanation of each manifest. This is a learning moment, not just file generation.

• Confirm that Hermes created the k8s/ directory with both files by running:

ls k8s/

You should see deployment.yaml and service.yaml listed in the output.

Don't see the k8s directory?

Make sure you are running ls from the repository root. If Hermes placed the files in a different location, ask it to move them into a k8s/ directory at the repository root.

Help me find where Hermes placed my Kubernetes manifests

Validate manifests with kubeconform

File existence is not proof of correctness. A YAML file can exist but contain invalid field names, wrong API versions, or structural errors that would crash a real deployment. This is where kubeconform steps in.

kubeconform validates Kubernetes manifests against official JSON schemas downloaded from the internet. No cluster required.

• Ask Hermes to validate the manifests by giving it this prompt:

Validate the Kubernetes manifests by running kubeconform with the -strict and -summary flags against both k8s/deployment.yaml and k8s/service.yaml. Show me the full output.

If any validation errors appear, fix the manifests and re-validate until everything passes. Explain what you fixed and why.

What do the flags do?

The -strict flag disallows additional properties not in the schema or duplicated keys. This catches typos and nonexistent fields that YAML would silently accept.

The -summary flag prints a summary at the end showing how many resources were valid, invalid, or skipped. This gives a clear pass/fail signal.

Before you read Hermes's output, predict: do you think the manifests will pass validation on the first attempt, or will Hermes need to fix something?

Look at the terminal output from Hermes. The kubeconform summary should show all resources as valid with zero invalid or errored entries. If Hermes had to fix issues and re-run, you have just witnessed the generate-then-verify loop in action.

Why validate before committing?

This is the core pattern of Part 4: generate, then verify. A DevOps engineer never pushes config they have not tested. By running kubeconform locally, Hermes catches schema errors before they reach the repository.

If Hermes fixed something and re-validated, that loop is exactly how human engineers work. The difference is Hermes does it in seconds.

Hermes says kubeconform is not found?

Make sure the kubeconform binary is in your PATH. If you installed it to the current directory, Hermes may need to reference it as ./kubeconform instead. Ask Hermes to try the full path or move the binary to a directory in your PATH.

Help me make kubeconform accessible to Hermes

Generate operations documentation and commit

Valid manifests are only useful if a human knows how to deploy and roll back the application. Operations documentation bridges the gap between validated config and a real production handover.

• Ask Hermes to generate the operations documentation and commit everything by giving it this prompt:

Generate two operations documents:

1. DEPLOYMENT.md - Include: step-by-step deployment instructions, required environment variables, infrastructure requirements, and a production readiness checklist. Reference the actual files in our repository (Dockerfile, docker-compose.yml, k8s/ manifests, ci.yml).

2. ROLLBACK.md - Include: rollback strategy, health check endpoints, and incident response steps. Reference the actual Kubernetes manifests and Docker configuration.

After generating both documents, commit all new files (k8s/deployment.yaml, k8s/service.yaml, DEPLOYMENT.md, ROLLBACK.md) with a commit message that confirms the Kubernetes manifests passed kubeconform validation.

What makes good operations documentation?

The key difference between useful ops docs and generic templates is specificity. DEPLOYMENT.md should reference your actual Dockerfile, your actual CI pipeline, and your actual manifest paths. ROLLBACK.md should name the specific Kubernetes resources it would roll back.

A human DevOps engineer should be able to pick up these documents and execute a deployment without asking any clarifying questions.

• Confirm the commit succeeded by asking Hermes to show the most recent commit message.

The commit message should mention that kubeconform validation passed. This is traceability. Anyone reading the git log can see that manifests were verified, not just generated.

• Verify that both documentation files exist in the repository by running:

ls DEPLOYMENT.md ROLLBACK.md

You should see both filenames listed without any "No such file" errors.

• Open DEPLOYMENT.md and confirm it references actual files from your repository (like Dockerfile, docker-compose.yml, k8s/deployment.yaml).
• Open ROLLBACK.md and confirm it includes a rollback strategy and references the Kubernetes manifests.

Documentation looks generic or template-like?

If the docs contain placeholder text like "your-app" or "your-image" instead of referencing your actual repository files, ask Hermes to regenerate them with explicit references to the files in your scaffold. Remind it to inspect the repository structure first.

Help me get Hermes to generate specific documentation

Your repository is now genuinely deployment-ready. Every artifact has been validated before committing. The manifests pass schema checks. The documentation references real files. A human DevOps engineer could pick up this repository and run a production deployment from what Hermes prepared.

Secret mission

Kick Off Continuous Delivery

Your repository is deployment-ready, but what about every future change? Right now, CI only runs when code hits main. That means broken code could land on the default branch before anyone catches it. Promote your DevOps Engineer from one-time setup to ongoing governance by establishing continuous delivery practices.

Clean Up Your Resources

Clean Up Your Resources

This project runs entirely on GitHub's free tier, so there are no ongoing monetary costs. The CI workflow will continue to consume free-tier minutes (2,000 per month for free accounts) on future pushes to your repository.

Decide whether to keep your resources running, pause them to come back later, or delete them entirely.

Resources you used:

• GitHub Actions CI workflow (triggers on pushes and pull requests, consumes free-tier minutes).
• GitHub repository (contains all committed files: Dockerfile, manifests, documentation, workflow).
• hadolint binary (installed locally for Dockerfile linting).
• kubeconform binary (installed locally for Kubernetes manifest validation).

Keep everything running

No action needed. Choose this if you are still actively building on this repository or plan to push more code soon.

• The CI pipeline will run automatically on future pushes and pull requests. Each run consumes a small number of minutes from your free-tier allowance.
• The hadolint and kubeconform binaries remain on your machine for future use.
• All committed files (Dockerfile, manifests, documentation, workflow) stay in your repository.

Pause - I'll come back to this later

Disable the CI workflow so it stops consuming minutes while you are away. Your repository and local binaries stay intact.

• Open your repository on GitHub and click the Actions tab.
• In the left sidebar, click the CI workflow.
• Click the dropdown and select Disable workflow.
• To re-enable later, return to the same page and click Enable workflow.

Delete - I don't want to use this again

Remove all project resources and start fresh. This permanently deletes the repository, workflow history, and all committed files.

• Delete the GitHub repository:
• Open your repository on GitHub and click Settings.
• Scroll down to the Danger Zone section and click Delete this repository.
• Click I want to delete this repository, then click I have read and understand these effects.
• Type the repository name to confirm and click Delete this repository.
• Remove the local hadolint binary:

rm hadolint

• Remove the local kubeconform binary:

rm kubeconform

That's a Wrap!

That's a Wrap!

Nice work! You just turned Hermes into a DevOps Engineer that validates its own output before committing anything to the repository.

You can point to your TaskFlow repository and say: "My AI agent prepared this for production and verified every piece of config before committing it."

What you learned:

• Taught an AI agent the generate-then-verify loop: Hermes creates artifacts, runs linting and validation tools (hadolint, kubeconform), and fixes its own mistakes before anything touches the repository.
• Built a real CI/CD pipeline and had Hermes push it, monitor the run via GitHub MCP actions tools, diagnose any failures from the logs, and confirm a green checkmark.
• Produced a deployment-ready repository with validated Docker configuration, linted Kubernetes manifests, and operations documentation (deployment and rollback playbooks) that a human engineer would actually hand over.
• Secret Mission: Established continuous delivery practices with branch protection recommendations, release guidelines, and a production release checklist.

Ready to quiz yourself?