Build an AI DevOps Organization

Automate incident detection and triage with a cron-scheduled SRE agent.

Introduction

30 Second Summary

Software teams ship code constantly, but shipping is only half the battle. The other half is knowing when something breaks and responding before users notice.

In this project, you will build the DevOps arm of your AI software company from Part 4. You'll create an SRE agent that monitors your repository on a schedule, detects failures automatically, and dispatches an AI incident responder to triage problems without you lifting a finger.

What You'll Build

You can break your repository on purpose, watch a health check fire on schedule, see a Kanban task appear automatically, and observe an AI incident responder triage the failure and post its findings.

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

  • A health check script that inspects the TaskFlow repo for structural issues (missing files, broken references, stale issues) and stays silent when everything is healthy.
  • A cron-scheduled monitoring job that runs every few minutes unattended and only alerts when something goes wrong.
  • An automated incident pipeline where failures create Kanban tasks assigned to an AI agent loaded with the code review skill, going from detection through triage with zero manual intervention.
  • A live Kanban board showing tasks flowing from creation through triage to completion, proving your DevOps arm works end-to-end.
  • Secret Mission: Build a multi-check SRE pipeline that chains code quality inspection with structural health checks, teaching the SRE to synthesize multiple signals into single actionable tickets.

Are there any prerequisites?

This is Part 5 of the Hermes Agent series. You need to have completed Part 4 (Multi-Agent Software Company with Hermes) so you have a TaskFlow repository with Sprint 1 artifacts.

If you deleted your setup from Part 4, don't worry. Step 1 includes instructions to restore everything you need.

Before We Start

Before we dive in, let's lock in what you're about to build and why it matters.

Your AI software company shipped code in Part 4. Now you're standing up the DevOps arm that keeps it alive.

Verify Your Environment

Your agents need infrastructure before they can do anything useful. A missing gateway or expired API key means nothing fires on schedule.

You will not discover these problems until Step 4 when your cron job silently fails to run. Let's verify everything now so you can trust the automation later.

In this step, get ready to:
  • Confirm Hermes Agent is installed and healthy.
  • Start the gateway daemon (required for cron jobs to fire).
  • Verify GitHub MCP connectivity and TaskFlow repository access.
Verify your Hermes installation

The hermes doctor command runs a diagnostic sweep of your Hermes Agent installation. It checks for missing dependencies, stale configurations, and connectivity issues in one pass.

  • Run the Hermes health check by entering this command:
hermes doctor

✔️ No critical issues reported

Your Hermes installation is healthy. Move on to the gateway check below.

ⓧ I see critical issues

Critical issues usually mean a missing API key or broken tool configuration. Run the setup wizard to repair your configuration:

hermes setup

Follow the interactive prompts to reconfigure your model provider and tools. Once setup completes, run hermes doctor again to confirm all issues are resolved.

ⓧ Command not found

Hermes Agent is not installed on this machine. Install it by running:

curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash

After installation completes, close and reopen your terminal so the hermes command is available. Then run hermes doctor to confirm a clean installation.

Start the gateway daemon

The gateway is the background process that fires cron jobs on schedule and dispatches Kanban tasks to workers. Without a running gateway, nothing in this project will execute automatically.

  • Check whether the gateway is already running by entering this command:
hermes gateway status

✔️ Gateway is running

Your gateway is active and ready to fire cron jobs. No action needed here.

ⓧ Gateway is not running

Start the gateway as a background service by running:

hermes gateway start
  • Confirm it started successfully by running hermes gateway status again.
  • You should see a message indicating the gateway is active with a PID number.

Gateway won't start?

Try running the gateway in the foreground to see errors directly:

hermes gateway

Common causes include a port conflict or missing API key. If you see an authentication error, run hermes setup to reconfigure your model provider. Once the issue is resolved, stop the foreground gateway with Ctrl+C and start it properly with hermes gateway start.

Help me troubleshoot my gateway

Verify GitHub MCP and TaskFlow repository access

Your health check script in Step 3 will use the GitHub CLI (gh) to inspect the TaskFlow repository. The SRE agent will also access the repo through GitHub MCP when triaging incidents. Both paths need to work.

  • Test that the Hermes default profile can reach your TaskFlow repository by running this quick query:
hermes chat -q "List the top-level files in my TaskFlow repository"

Before you press Enter, what do you expect to see? Think about what files your AI team committed in Part 4.

You should see Hermes respond with a list of files from your TaskFlow repository, including README.md, ARCHITECTURE.md, and PRODUCT-REQUIREMENTS.md from the Sprint 1 artifacts your team created in Part 4.

What does this prove?

A successful response confirms two things at once. First, the GitHub MCP server is connected and authenticated. Second, your TaskFlow repository from Part 4 still exists and is accessible to your agents.

Hermes can't find the repository?

Make sure the GitHub MCP tool is enabled. Run hermes tools and confirm GitHub is listed among your active tools.

If GitHub MCP is missing, reconfigure it with hermes setup and select GitHub when prompted for tool integrations.

Help me reconnect GitHub MCP

Your infrastructure is confirmed and ready. Next up, you will create the SRE profile that gives your DevOps arm its own identity and AI brain.

Create the SRE Profile

Your engineering team from Part 4 has builders. Frontend, backend, QA. But nobody is watching for fires.

Without a dedicated monitoring identity, health checks have no home and incidents have no responder. In this step, you will create an SRE profile with its own AI brain, giving your software company its first DevOps agent.

In this step, get ready to:
  • Create the SRE profile and write its SOUL.md identity document.
  • Configure the model provider for the SRE agent.
  • Validate the profile responds correctly and can access the TaskFlow repository.
Create the SRE profile and write its identity

Every Hermes profile needs two things: a configuration scaffold and a SOUL.md that defines who the agent is. The --clone flag copies the default profile's structure so you start with a working foundation.

  • Create the SRE profile by running this command:
hermes profile create sre --clone

What does this command do?

The --clone flag copies config.yaml, .env, SOUL.md, and skills from your default profile into a new directory at ~/.hermes/profiles/sre/.

This gives the SRE its own isolated identity, memory, and configuration. Changes you make here do not affect your other profiles.

  • Confirm the profile was created by running:
ls ~/.hermes/profiles/sre/

You should see config.yaml, .env, SOUL.md, and a skills/ directory listed in the output.

Now you need to rewrite the SOUL.md so the SRE knows its job is monitoring and incident response, not general-purpose chat.

  • Open ~/.hermes/profiles/sre/SOUL.md in your text editor and replace its entire contents with the following:
# SRE - Site Reliability Engineer

## Identity

You are the Site Reliability Engineer for the TaskFlow project. Your primary responsibility is monitoring repository health, detecting incidents, and triaging failures before they impact the team.

## Core Responsibilities

- Run health checks against the TaskFlow repository on a scheduled basis.
- Detect structural issues, stale issues, and CI failures early.
- Triage incidents by analyzing root cause and impact.
- Create Kanban tasks for confirmed incidents with clear descriptions and remediation steps.

## Escalation vs Resolution

- **Resolve directly** when: the issue is a known pattern (stale issue, missing file that can be regenerated, minor CI flake).
- **Escalate via Kanban** when: the issue requires code changes, involves multiple files, or impacts other team members' work.

## Coordination

- All incident tracking flows through the Kanban board.
- Every confirmed incident becomes a Kanban task with severity, affected components, and suggested remediation.
- Never resolve silently. All actions must be visible on the board.

What does this SOUL.md establish?

  • The Identity section tells the AI it is an SRE focused on the TaskFlow project.
  • Core Responsibilities scope it to health checks, detection, triage, and Kanban task creation.
  • Escalation vs Resolution gives the agent clear criteria for when to fix something itself versus when to open a ticket for another agent.
  • Coordination ensures all work is visible on the board. No silent fixes that the team cannot see.
  • Save the file.
  • Confirm the contents were saved by running:
head -5 ~/.hermes/profiles/sre/SOUL.md

You should see the first five lines of your new SOUL.md, starting with # SRE - Site Reliability Engineer.

Still seeing the old SOUL.md content?

Make sure you replaced the entire file contents, not just appended to the end. Open the file again and verify it starts with # SRE - Site Reliability Engineer.

If your editor saved to a different path, check that you are editing ~/.hermes/profiles/sre/SOUL.md specifically, not the default profile's SOUL.md.

Help me fix my SRE SOUL.md file

Configure the model provider

The SRE profile needs an AI model to power its reasoning. You will use the sre model wizard to select a provider. Choose between the free and paid options below.

Free model (recommended)

You have two free options. Pick whichever provider you already have an API key for from Part 4.

Option A: Gemini 2.5 Flash (if you have a GEMINI_API_KEY from Part 4).

  • Verify your Gemini key is available to the SRE profile by running:
grep GEMINI_API_KEY ~/.hermes/profiles/sre/.env
  • If the key is not present, add it to the SRE profile's .env file by running:
echo "GEMINI_API_KEY=your-api-key-here" >> ~/.hermes/profiles/sre/.env
  • Run the model wizard and select gemini-2.5-flash:
sre model

The wizard will display available models. Select gemini-2.5-flash from the list.

Option B: OpenRouter Nemotron 3 Super (if you have an OPENROUTER_API_KEY from Part 4).

  • Verify your OpenRouter key is available to the SRE profile by running:
grep OPENROUTER_API_KEY ~/.hermes/profiles/sre/.env
  • If the key is not present, add it to the SRE profile's .env file by running:
echo "OPENROUTER_API_KEY=your-api-key-here" >> ~/.hermes/profiles/sre/.env
  • Run the model wizard and select nvidia/nemotron-3-super-120b-a12b:free:
sre model

The wizard will display available models. Select nvidia/nemotron-3-super-120b-a12b:free from the list. This is a 120B parameter model with a 1M context window, available for free on OpenRouter.

Paid model (Claude Sonnet)

If you have an Anthropic subscription or API key, you can use Claude Sonnet for higher-quality triage reasoning.

  • Run the model wizard on the SRE profile:
sre model
  • Select Anthropic from the provider list.
  • Follow the OAuth flow or enter your Anthropic API key when prompted.

Why pay for the SRE?

The SRE performs reasoning-heavy triage: analyzing failure reports, deciding severity, and writing clear Kanban task descriptions. Claude Sonnet excels at this kind of structured reasoning. The free models work well too, so this is entirely optional.

Validate the profile and verify repository access

Before you rely on the SRE for automated monitoring, you need to confirm it responds correctly and can reach the TaskFlow repository through GitHub MCP.

Before you run the next command, what do you expect the SRE to say about its role? Think about what you wrote in the SOUL.md.

  • Test the SRE profile with a quick-query by running:
sre chat -q "What is your role?"

The SRE should identify itself as a Site Reliability Engineer focused on monitoring, incident detection, and triage for the TaskFlow project. It should mention the Kanban board as its coordination mechanism.

SRE not responding or giving a generic answer?

  • If you see an authentication error, your API key is missing or invalid. Re-check ~/.hermes/profiles/sre/.env and confirm the key is correct.
  • If the response is generic and does not mention SRE or TaskFlow, your SOUL.md was not saved correctly. Run cat ~/.hermes/profiles/sre/SOUL.md and verify the content.
  • If you get a model-not-found error, re-run sre model and confirm your model selection was saved.

Help me troubleshoot my SRE profile not responding correctly

  • Now confirm the SRE can access the TaskFlow repository by running:
sre chat -q "List the files in the root of the TaskFlow repository."

You should see the SRE list files from your TaskFlow repo, including README.md, ARCHITECTURE.md, and PRODUCT-REQUIREMENTS.md. This proves the GitHub MCP connection is working for this profile.

Why verify repository access separately?

The SRE profile cloned the default profile's MCP connections. In most cases this means GitHub access carries over automatically. However, if you changed your default profile's MCP setup since Part 4, the clone may not have the right connection. Catching this now saves you from a silent failure when cron jobs start firing in Step 4.

Your SRE agent is alive and ready to watch. Next up, you will give it eyes on the repository by writing a health check script that inspects TaskFlow for structural problems.

Write and Run the Health Check

Your SRE agent has an identity and a brain. Now it needs eyes on the repository.

Without a concrete signal to act on, your monitoring profile is just a fancy config file. In this step, you will write a bash script that inspects the TaskFlow repository for structural problems using the gh CLI. Running it manually first proves the script works before you hand it to a scheduler.

In this step, get ready to:
  • Write a health check script that inspects repository structure, stale issues, and CI status.
  • Review the script to understand what each check does and what triggers a failure.
  • Run the script manually and confirm it passes silently on a healthy repository.
Write the health check script

Hermes cron jobs look for scripts in a specific directory. You need to create that directory and write your health check there.

  • Create the scripts directory by running this command:
mkdir -p ~/.hermes/scripts
  • Create and open the health check script in your editor:
nano ~/.hermes/scripts/taskflow-healthcheck.sh

Use any editor you prefer

You can use nano, vim, VS Code, or any text editor. The important thing is the file ends up at ~/.hermes/scripts/taskflow-healthcheck.sh.

  • Paste the following code into the file. This is the first half of the script, covering the header and the first two checks:
#!/bin/bash
# TaskFlow repository health check
# Silent on success (no stdout). Prints failure report on problems.

REPO="[[TASKFLOW_REPO="your-username/TaskFlow"]]"
FAILURES=""

# Check 1: Key files must exist in the repository
for file in README.md ARCHITECTURE.md PRODUCT-REQUIREMENTS.md; do
  if ! gh api "repos/$REPO/contents/$file" --silent 2>/dev/null; then
    FAILURES="$FAILURES\n- Missing required file: $file"
  fi
done

# Check 2: No issues open longer than 7 days without a comment
CUTOFF=$(date -d "7 days ago" +%Y-%m-%dT%H:%M:%SZ)
STALE_ISSUES=$(gh issue list --repo "$REPO" --state open \
  --json number,title,comments,createdAt \
  --jq '.[] | select(.createdAt < "'"$CUTOFF"'" and .comments == 0) | "#\(.number): \(.title)"')

if [ -n "$STALE_ISSUES" ]; then
  FAILURES="$FAILURES\n- Stale issues (open >7 days, no comments):\n$STALE_ISSUES"
fi

What does this code do?

  • REPO stores your GitHub username and repository name so every gh command targets the right repo.
  • Check 1 loops through three critical files and uses gh api to query the GitHub Contents API. If a file does not exist, the API returns a 404 and gh exits non-zero, which triggers the failure message.
  • Check 2 fetches all open issues as JSON, then uses --jq to filter for issues created more than 7 days ago with zero comments. The comments field is an integer count of comments per issue.
  • Continue pasting the second half of the script directly below. This adds the CI status check and the reporting logic:
# Check 3: No failed CI status on the default branch
DEFAULT_BRANCH=$(gh api "repos/$REPO" --jq '.default_branch' 2>/dev/null)
if [ -n "$DEFAULT_BRANCH" ]; then
  CI_STATE=$(gh api "repos/$REPO/commits/$DEFAULT_BRANCH/status" --jq '.state' 2>/dev/null)
  if [ "$CI_STATE" = "failure" ]; then
    FAILURES="$FAILURES\n- CI status is FAILED on branch $DEFAULT_BRANCH"
  fi
fi

# Report: non-empty FAILURES = problems found
if [ -n "$FAILURES" ]; then
  echo "=== TaskFlow Health Check FAILED ==="
  echo -e "$FAILURES"
  exit 1
fi

# Success: exit silently (no stdout = no alert in Hermes cron)
exit 0

What does the reporting logic do?

  • Check 3 queries the repository's default branch, then fetches the combined commit status. If the state is failure, it appends a message to FAILURES.
  • The reporting block at the bottom is the key pattern: if FAILURES is non-empty, the script prints a report and exits with code 1. If FAILURES is empty, the script produces no stdout and exits with code 0.
  • This silent-on-success pattern is exactly what Hermes cron expects. Empty stdout means a silent tick with no delivery. Non-empty stdout means something needs attention.
  • Save the file and exit your editor.
  • Make the script executable by running:
chmod +x ~/.hermes/scripts/taskflow-healthcheck.sh
  • Confirm the script exists in the right location by running:
ls ~/.hermes/scripts/

You should see taskflow-healthcheck.sh listed in the output.

Don't see the file?

  • Make sure you saved correctly in your editor. In nano, press Ctrl+O to write and Ctrl+X to exit.
  • Double-check the path. The file must be at ~/.hermes/scripts/taskflow-healthcheck.sh (inside the hidden .hermes directory in your home folder).

My health check script isn't appearing in the scripts directory.

Review the script before running it

Before trusting any script to run unattended, you should understand exactly what it does and what would make it report a failure.

Why review before running?

In a production SRE workflow, you never blindly trust automation. The same principle applies here. Understanding your checks means you can predict what will trigger an alert and what will stay silent.

For Hermes cron specifically: empty stdout equals a silent tick with no message sent. Any output to stdout equals a delivery to the target. Your script uses this convention so a healthy repo produces zero noise.

Run the health check manually

The TaskFlow repository is currently healthy. All three key files exist from Part 4, there are no stale issues, and there is no failed CI. This means the script should produce nothing.

  • Before you run the script, predict: what do you expect to see in your terminal? Will there be any output?
  • Run the health check manually:
bash ~/.hermes/scripts/taskflow-healthcheck.sh
  • Check the exit code by running:
echo $?

You should see absolutely no output from the script itself, and the exit code should be 0. Silence means success. The repository is healthy and there is nothing to report.

Seeing output or a non-zero exit code?

  • If you see a "Missing required file" message, check that your TaskFlow repository still has README.md, ARCHITECTURE.md, and PRODUCT-REQUIREMENTS.md from Part 4.
  • If you see a permission error, verify your gh CLI is authenticated. Run gh auth status to confirm.
  • If you see a stale-issues failure, check whether you have an old test issue from Part 4 that was never closed. Close it in the GitHub UI, then re-run.

My health check script is producing unexpected output on a repository I think is healthy.

✔️ Awesome, I've got everything!

Great. Double check you saved the file and that it runs silently. Your health check is ready to be scheduled.

ⓧ I'd like to double check the full code

Your complete ~/.hermes/scripts/taskflow-healthcheck.sh should contain all of the following, in order:

  • The shebang line, REPO variable, and FAILURES initialization.
  • Check 1: the for loop checking README.md, ARCHITECTURE.md, and PRODUCT-REQUIREMENTS.md.
  • Check 2: the CUTOFF date calculation, gh issue list with --jq filtering, and the stale-issues conditional.
  • Check 3: the DEFAULT_BRANCH lookup, CI_STATE query, and the failure conditional.
  • The report block that prints on failure or exits silently on success.

Scroll up and confirm each chunk is present in your file, in that order.

Your health check works. It runs against the live repository, checks structural health, and follows the silent-on-success pattern. Next up, you will wire this script into the Hermes cron scheduler so it fires automatically on a repeating schedule.

Schedule the Health Check and Trigger a Failure

Your health check script works. You proved it in the last step by running it manually and confirming it passes silently on a healthy repo.

Running it manually is not DevOps. Real monitoring runs unattended on a schedule, catching problems while you sleep. In this step, you will wire the script into Hermes' cron scheduler so it fires every five minutes without you touching anything. You will also discover a critical limitation: when the check finds a problem, the report lands in a local file with nobody acting on it.

In this step, get ready to:
  • Schedule the health check as an automated no-agent cron job.
  • Introduce a deliberate failure into the TaskFlow repository.
  • Trigger the job and observe the gap between detection and action.
Schedule the no-agent cron job

Hermes cron supports a no-agent mode that runs scripts without any LLM involvement. If the script produces empty stdout, it counts as a silent tick and nothing happens. If stdout is non-empty, the output gets delivered to a target.

  • Schedule the health check on the SRE profile by running this command:
sre cron create "every 5m" --no-agent --script taskflow-healthcheck.sh --deliver local --name "taskflow-healthcheck"

What does this command do?

  • sre cron create creates a cron job scoped to the SRE profile.
  • "every 5m" sets the schedule to fire every 5 minutes.
  • --no-agent means no LLM runs. The script executes raw, saving you tokens on quiet ticks.
  • --script taskflow-healthcheck.sh points to the script you wrote in ~/.hermes/scripts/.
  • --deliver local saves any non-empty output to ~/.hermes/cron/output/ rather than sending it to an agent.
  • Confirm the job was created by running:
hermes cron list

You should see your taskflow-healthcheck job listed as [active].

Job not showing as active?

  • Make sure the gateway is running. Cron jobs require a running gateway to fire. Check with hermes gateway status.
  • Verify the script path resolves. The script must live in ~/.hermes/scripts/ and the filename must match exactly.

Still stuck? Why isn't my cron job showing as active in hermes cron list?

Introduce a deliberate failure in the repository

The cron job fires every 5 minutes, but the repo is healthy right now. Your health check will produce empty stdout and stay silent. To see the monitoring system catch a real problem, you need to break something on purpose.

  • Remove ARCHITECTURE.md from the TaskFlow repository using the GitHub API. First, get the file's SHA by running:
gh api repos/{owner}/{repo}/contents/ARCHITECTURE.md --jq '.sha' -R [[TASKFLOW_REPO="your-username/TaskFlow"]]
  • Copy the SHA string from the output. Then delete the file by running:
gh api --method DELETE repos/{owner}/{repo}/contents/ARCHITECTURE.md \
  -f message="test: remove file to trigger health check" \
  -f sha="[[FILE_SHA="the SHA you copied above"]]" \
  -R [[TASKFLOW_REPO="your-username/TaskFlow"]]

Why delete a real file?

Your health check script verifies that README.md, ARCHITECTURE.md, and PRODUCT-REQUIREMENTS.md exist. Removing one triggers the missing-file check, producing stdout output that the cron system will deliver.

This is a standard SRE practice called chaos engineering. You deliberately inject failures to verify your monitoring catches them.

You should see a JSON response confirming the commit that deleted the file.

Seeing a 404 or permission error?

  • Double-check the -R flag points to your actual repository in owner/repo format.
  • Make sure the file exists at the repository root. If your project structure has it nested in a subdirectory, adjust the path.
  • Confirm your gh token has write access to the repository.

Need help? I am getting an error when trying to delete a file from my GitHub repo using gh api.

Trigger the job and observe the gap

The cron job fires every 5 minutes automatically, but you do not need to wait. You can trigger it immediately to prove it catches the problem you just introduced.

  • Note the job ID from hermes cron list (the first column). Then trigger the job manually by running:
hermes cron run [[CRON_JOB_ID="your job ID from hermes cron list"]]

Before you check the output, think about what you expect to happen. The script should detect the missing ARCHITECTURE.md and produce a failure report. Where does that report end up?

  • Check the cron output directory by running:
ls ~/.hermes/cron/output/

You should see a directory named after your job ID. Look inside it.

  • Read the failure report by running:
cat ~/.hermes/cron/output/[[CRON_JOB_ID="your job ID"]]/$(ls -t ~/.hermes/cron/output/[[CRON_JOB_ID="your job ID"]]/ | head -1)

You should see a report mentioning that ARCHITECTURE.md is missing from the repository.

Now step back and notice what happened. The script found the problem. The cron scheduler delivered the report to a file. But the file is sitting on disk. Nobody is reading it. Nobody is opening a ticket. Nobody is triaging the failure. The monitoring detected the fire, but there is no firefighter responding.

This gap is intentional

This is exactly the limitation of no-agent cron with local delivery. Detection without response is not DevOps. In the next step, you will close this loop by upgrading the job to create Kanban tasks that dispatch an AI incident responder automatically.

Your monitoring system detects problems, but it has no hands. The failure report sits in a file like a fire alarm ringing in an empty building. Next up, you will give the system hands by wiring Kanban auto-ticketing and dispatching an AI incident responder.

Wire Kanban Auto-Ticketing and Incident Dispatch

Your health check script catches problems. It fires on schedule, detects the broken repository, and writes a failure report to a local file. But that file just sits there. Nobody reads it, nobody acts on it, and the problem festers until a human happens to check.

This is the gap between monitoring and incident response. In this step, you will upgrade the cron job from a silent no-agent watchdog to an LLM-backed job that triggers an automated response pipeline: on failure, the SRE agent creates a Kanban task, assigns it to itself with the github-code-review skill, and triages the incident without you lifting a finger.

In this step, get ready to:
  • Upgrade the health check from a no-agent cron job to an LLM-backed cron job with a self-contained prompt.
  • Trigger the failure and watch the Kanban dispatcher spawn the SRE worker with the github-code-review skill to triage the incident.
  • Verify the task moves through ready, running, and done on the Kanban board.
Remove the old no-agent job and create the LLM-backed replacement

Your current cron job runs in no-agent mode. It executes the script and dumps stdout to a local file. To close the loop, you need the SRE agent to reason about the script output and take action. This means removing the no-agent job and creating a new LLM-backed job with a cron prompt.

  • First, find your existing job ID by running:
  • Initialize the Kanban database (if not already present) by running:
hermes cron list

You should see your taskflow-healthcheck job listed as [active]. Note the job ID displayed next to the name.

  • Remove the existing no-agent job by running (replace the job ID with yours):
hermes cron remove [[HEALTHCHECK_JOB_ID="your taskflow-healthcheck job ID"]]
  • Initialize the Kanban board so tasks can be stored by running:
hermes kanban init

Why remove and recreate instead of editing?

You could use hermes cron edit to flip the job from no-agent to LLM mode. However, recreating the job makes the full command visible in your terminal history. You can see every flag and the entire prompt at a glance, which makes debugging much easier.

  • Create the new LLM-backed cron job by running the following command. This is a single command with a long prompt. The prompt must be completely self-contained because cron jobs run in fresh sessions with no memory of your conversations:
hermes cron create "every 5m" \
  "You are the SRE agent for the TaskFlow repository. A health check script has just run and its output is below. Your job:
1. Read the script output carefully.
2. If the output is empty, everything is healthy. Respond with [SILENT].
3. If the output contains failure details, create a Kanban task using kanban_create with:
   - A clear title summarizing the failure
   - assignee: sre
   - skills: github-code-review
   - Body: include the full failure details from the script output
4. After creating the task, respond with a brief confirmation of what you filed.
Repository: TaskFlow. Do NOT attempt to fix the issue yourself. Your only job is to detect and file." \
  --script taskflow-healthcheck.sh \
  --skill github-code-review \
  --name "taskflow-healthcheck" \
  --deliver local

What does this command do?

This creates an LLM-backed cron job that combines your existing health check script with an AI agent. Every 5 minutes, the scheduler runs taskflow-healthcheck.sh and injects its stdout into the SRE agent's prompt as context.

If stdout is empty (healthy repo), the agent responds with [SILENT] and no delivery happens. If stdout contains a failure report, the agent reads it and calls kanban_create to file an incident task with the github-code-review skill attached. The --skill github-code-review flag loads the skill's SKILL.md as context so the agent knows how to review code.

  • Confirm the new job was created by running:
hermes cron list

You should see taskflow-healthcheck listed as [active] again. This time it is LLM-backed (no "no-agent" marker in the output).

Job creation failed?

  • If you see a gateway lifecycle error, make sure your gateway is running. Return to your terminal and run hermes gateway start.
  • If the error mentions a missing schedule, double-check you included "every 5m" as the first argument after create.
  • If you see a skills error, verify the skill exists by running hermes skills list and checking for github-code-review in the output.

help me debug my cron job creation error

Review the cron prompt before triggering

Cron jobs run in fresh agent sessions with zero memory of your previous conversations. The prompt you wrote is the only instruction the SRE agent receives. Before triggering the failure, take a moment to review whether it covers everything.

  • Re-read the prompt in the cron create command above and ask yourself these questions:
  • Does it specify what to do on success (respond with [SILENT])?
  • Does it specify what to do on failure (create a Kanban task)?
  • Does it name the assignee and skill for the Kanban task?
  • Does it include the repository name so the agent has context?
  • Does it tell the agent NOT to fix the issue itself (separation of detection from remediation)?

Why is this review step important?

A bad cron prompt is invisible until it fires. If you forget to include the repository name or the skill attachment, the agent will hallucinate context or skip the Kanban task entirely. Unlike interactive chat, you cannot course-correct mid-run.

The prompt follows a self-contained pattern: include ALL context, ALL instructions, and ALL edge cases. The agent has no memory, no access to your SOUL.md preferences, and no awareness of what you set up in previous steps.

Trigger the failure and watch the incident pipeline

Your repository is still broken from the previous step. The health check will produce output, the SRE agent will read it, and the Kanban pipeline should kick in. Time to see it work end-to-end.

  • Before you trigger the job, predict what will happen. Do you think the SRE agent will successfully create a Kanban task on the first try? What could go wrong?
  • Trigger the cron job immediately (no need to wait 5 minutes) by running:
hermes cron run [[HEALTHCHECK_JOB_ID="your taskflow-healthcheck job ID"]]

The gateway picks up the triggered job on the next scheduler tick (within 60 seconds). The SRE agent spins up in a fresh session, reads the health check script's output, and processes it against the cron prompt.

  • Wait about 60-90 seconds for the dispatcher to process the job. Then check the Kanban board by running:
hermes kanban list

You should see a new task assigned to sre with a status that may show ready, running, or done depending on timing. The task title should describe the health check failure.

What is happening behind the scenes?

When the cron job fires, the scheduler runs your bash script. Its stdout (the failure report) gets injected into the agent's prompt. The SRE agent reads it, calls kanban_create with the title, assignee, skill, and failure body. The Kanban dispatcher (running in the gateway) sees the new task, spawns the sre profile as a worker loaded with the github-code-review skill, and the worker triages the incident.

The dispatcher ticks every 60 seconds. This is why you may need to wait a moment for the task to progress through its lifecycle states: ready (filed), running (worker is triaging), done (triage complete).

  • If the task shows running, wait another minute and re-run hermes kanban list until you see it reach done.
  • Once the task is done, open the Kanban dashboard to see the full incident lifecycle visually by running:
hermes dashboard

The dashboard opens a web UI with a Kanban tab. You should see your incident task card in the done column. Click on it to read the completion summary. The triage findings should reference the specific failure your health check detected (the stale issue or missing file you introduced earlier).

Task stuck in ready or not appearing?

  • Verify the gateway is running with hermes gateway status. The dispatcher only ticks when the gateway is active.
  • Check that the cron job actually fired by looking for new output in ~/.hermes/cron/output/. If no new files appeared, the job did not execute.
  • If you see a task but it stays in ready for more than 2 minutes, the dispatcher may not be matching the skill requirement. Confirm the SRE profile has the skill available by running hermes skills list and looking for github-code-review.

help me figure out why my Kanban task is stuck

Read the task's completion summary in the dashboard. The SRE agent should have identified the specific issue (the stale GitHub Issue or missing file), explained its impact, and provided a recommendation. This is your incident pipeline working end-to-end: detection to triage with zero manual intervention.

Your DevOps pipeline is live. The health check fires on schedule, the SRE agent files Kanban tasks on failure, and a skill-loaded worker triages the incident automatically. You have gone from a script writing to a file that nobody reads, to a full incident lifecycle from detection through AI-powered triage. Next up, you will extend this with a second health check in the Secret Mission.

Secret mission

Build a Multi-Check SRE Pipeline

Your single health check catches structural issues like missing files and stale issues. But what about code quality? Real SRE teams run multiple checks that feed a unified incident pipeline. Can you build a second check that inspects code quality, chain it with the first using context_from, and teach your SRE to synthesize both signals into a single actionable ticket?

Clean Up Your Resources

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. This project runs entirely locally with free-tier API keys, so there are no ongoing costs.

Resources you used:

  • Hermes SRE profile (stored at ~/.hermes/profiles/sre/).
  • Hermes cron jobs (stored in ~/.hermes/cron/jobs.json).
  • Hermes Kanban tasks (stored locally in ~/.hermes/kanban.db).
  • Health check scripts at ~/.hermes/scripts/.
  • Hermes gateway (running as a background process).
  • GitHub Issues created for testing in the TaskFlow repository.

Keep everything running

No action needed. Choose this if you plan to continue building on the Hermes Agent series.

  • Your SRE profile, cron jobs, and Kanban tasks persist on disk.
  • The gateway continues running health checks on schedule.
  • Your health check scripts remain at ~/.hermes/scripts/ and will fire on each cron tick.

Pause - I'll come back to this later

Shut down the gateway to stop health checks from firing. All configuration persists on disk so you can resume later.

  • Stop the gateway by running:
hermes gateway stop
  • Cron jobs will not fire until you restart the gateway with hermes gateway start.
  • All profiles, scripts, and Kanban data remain on disk.

Delete - I don't want to use this again

Remove all project resources and start fresh. Follow each step in order.

  • Stop the gateway by running:
hermes gateway stop
  • Remove the SRE profile by running:
hermes profile delete sre

You will be asked to type the profile name to confirm deletion. This also stops any gateway running for that profile and removes its command alias.

  • List your cron jobs, then remove each one:
hermes cron list

For each job ID shown in the output, run the remove command:

hermes cron remove [[JOB_ID="job ID from the list above"]]

Repeat for every job ID until the list is empty.

  • Remove the health check scripts by running:
rm ~/.hermes/scripts/taskflow-healthcheck.sh
rm ~/.hermes/scripts/taskflow-codequality.sh
  • Clean up cron output files by running:
rm -rf ~/.hermes/cron/output/
  • Clean up Kanban tasks and old logs by running:
hermes kanban gc
  • Close or delete any test GitHub Issues you created in the TaskFlow repository. Open your repository's Issues tab on GitHub and close the ones you opened during this project.

Nice Work!

Nice Work!

You just stood up a fully automated DevOps arm for your AI software company. Your repository now has an SRE agent that monitors on a schedule, detects failures, opens incident tickets, and dispatches a specialist to triage them without you lifting a finger.

You learned how to:

  • Build an SRE profile with health check scripts that inspect your TaskFlow repository using the GitHub CLI, following the silent-on-success watchdog pattern where empty stdout means everything is healthy.
  • Schedule automated monitoring with Hermes cron no-agent mode, then experience the designed gap between detection and action when alerts land in a file with nobody responding.
  • Close the loop by wiring Kanban auto-ticketing with per-task skill attachment, creating a full incident pipeline from detection through AI-powered triage on the Kanban board.
  • Secret Mission: Built a multi-check SRE pipeline using context_from chaining, teaching the SRE agent to synthesize multiple signal sources into single actionable tickets.

Ready to quiz yourself?