Automate GitHub Issues with Hermes Agent

Build an AI pipeline that triages, fixes, and PRs GitHub issues autonomously.

Introduction

30 Second Summary

Open-source projects accumulate bug reports faster than maintainers can fix them. What if an AI agent could triage those issues, reproduce the bugs, and open pull requests while you sleep?

In this project, you will build an automated issue resolution pipeline using Hermes Agent and xAI Grok. Your system will monitor a GitHub repository, spawn parallel AI subagents to reproduce bugs and write fixes, and open pull requests automatically.

What You'll Build

An automated GitHub issue resolution system powered by Hermes Agent that monitors repositories, delegates bug fixes to parallel subagents, and opens pull requests autonomously.

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

  • Hermes Agent configured with xAI Grok OAuth and the GitHub skill for repository interaction.
  • A scheduled cron automation that sweeps issues by priority and delegates resolution to parallel subagents.
  • A GitHub webhook that triggers real-time issue response when new bugs are filed.
  • Secret Mission: Add intelligent issue filtering that uses Grok to assess complexity and skip issues too large for autonomous resolution.

Are there any prerequisites?

You need Hermes Agent installed on Windows, an X subscription (SuperGrok or X Premium+) for xAI Grok access, a GitHub account, and optionally Docker Desktop installed for sandboxed code execution.

Set Up Hermes with xAI Grok and GitHub CLI

Hermes Agent needs two things before it can work with GitHub repositories: an LLM provider to power its reasoning, and authenticated access to GitHub's API.

In this step, you will connect Hermes to xAI Grok via your X subscription (no API key needed), install the GitHub CLI, and configure a terminal backend where Hermes will execute code.

In this step, get ready to:
  • Configure xAI Grok OAuth as the LLM provider for Hermes.
  • Install and authenticate GitHub CLI so Hermes can interact with repositories.
  • Install the Hermes GitHub skill and configure a terminal backend.
Configure xAI Grok OAuth as the LLM provider

Hermes uses an LLM to reason about code and plan actions. Your X subscription (SuperGrok or X Premium+) grants OAuth-based access to xAI Grok models directly from Hermes, with no API key required.

  • Open the model selection prompt by running this command in your PowerShell terminal:
hermes model

What happens next?

A list of available LLM providers will appear in your terminal. Your browser will also open to complete an OAuth device-code flow with your X account.

  • Select xAI Grok OAuth (SuperGrok / X Premium+) from the provider list.
  • When prompted for a model, pick grok-build-0.1.
  • Complete the browser-based authentication with your X account when the window opens.

Prefer the direct route?

If you want to skip the interactive menu, set the provider and model directly by running these two commands:

hermes config set model.default grok-build-0.1
hermes config set model.provider xai-oauth

You will still need to complete the browser OAuth flow the first time Hermes connects to xAI.

  • Confirm the provider is connected by running:
hermes doctor
  • Look for the xAI Grok provider showing a connected status in the output.

Seeing HTTP 403 on OAuth?

Some SuperGrok subscribers hit a known issue (GitHub issue #26847) where OAuth inference returns a 403 error. If this happens to you, set an API key as a fallback instead:

  • Generate an API key from your xAI account dashboard.
  • Set the environment variable XAI_API_KEY to your key value, then switch the provider to xai with hermes config set model.provider xai.

Help me troubleshoot the xAI Grok OAuth 403 error in Hermes Agent.

Install and authenticate GitHub CLI

The GitHub CLI (gh) lets Hermes create branches, open pull requests, and interact with issues programmatically.

  • Install GitHub CLI by running this command:
winget install --id GitHub.cli

Why a new window is required

The installer adds gh to your system PATH, but your current terminal session does not pick up PATH changes automatically. You must close the entire PowerShell window and open a brand new one. Opening a new tab alone is not enough.

  • Close your current PowerShell window completely.
  • Open a new PowerShell window.
  • Verify the install worked by running:
gh --version

✔️ I see a version number

GitHub CLI is installed and on your PATH. Continue to the authentication step below.

ⓧ Command not found

Your terminal has not picked up the new PATH entry. Try these fixes:

  • Make sure you opened an entirely new PowerShell window (not a new tab in the same window).
  • If that still fails, manually refresh your PATH in the current session by running:
$env:Path = [System.Environment]::GetEnvironmentVariable("Path","Machine") + ";" + [System.Environment]::GetEnvironmentVariable("Path","User")
  • Run gh --version again to confirm.

Help me fix gh not being recognized after installing with winget.

  • Start the authentication flow by running:
gh auth login

What prompts will I see?

The CLI will ask a series of questions. Select these options:

  • Account: GitHub.com.
  • Preferred protocol: HTTPS.
  • Authenticate Git with GitHub credentials: Y.
  • Authentication method: Login with a web browser.

Your browser will open to complete the OAuth flow. Authorize the app when prompted.

  • Confirm authentication succeeded by running:
gh auth status
  • You should see your GitHub username and Logged in to github.com in the output.

Authentication failed?

If the browser flow did not complete or you see an error:

  • Make sure you completed the browser authorization before the code expired.
  • Run gh auth login again to retry the flow from scratch.

Help me debug GitHub CLI authentication issues.

Install the Hermes GitHub skill and configure terminal backend

The GitHub skill gives Hermes structured knowledge about common GitHub operations like creating branches, opening PRs, and commenting on issues. The terminal backend determines where Hermes executes code.

  • Install the GitHub skill by running:
hermes skills install github

What does this skill add?

The GitHub skill provides Hermes with step-by-step recipes for common operations: cloning, branching, committing, opening PRs, reviewing code, and posting comments. It also auto-forwards required environment variables (like GITHUB_TOKEN) into container sessions.

Next, configure the terminal backend. Hermes needs a place to run shell commands. You have two options:

Docker (recommended)

The Docker backend runs commands inside a persistent container. This is the safer choice for executing untrusted open-source code because the container acts as a security boundary.

  • Set the terminal backend to Docker and forward your GitHub token by running these commands:
hermes config set terminal.backend docker
hermes config set terminal.docker_forward_env '["GITHUB_TOKEN"]'

How much space does this use?

Hermes shares a single persistent container across all sessions and delegates. The default image (nikolaik/python-nodejs:python3.11-nodejs20) is approximately 900 MB. Docker Desktop must be running when you use Hermes.

Local (lightweight)

The local backend runs commands directly on your host machine via Git Bash. It uses zero extra disk space but has less isolation. Hermes will ask for approval before running potentially dangerous commands.

  • Set the terminal backend to local and forward your GitHub token by running these commands:
hermes config set terminal.backend local
hermes config set terminal.env_passthrough '["GITHUB_TOKEN"]'
  • Verify the GitHub skill is active by running:
hermes tools
  • Confirm that github appears in the enabled tools list in the output.

Don't see the GitHub skill listed?

If github does not appear in hermes tools output:

  • Run hermes skills install github again and check for error messages during installation.
  • Confirm that gh auth status still shows you as authenticated. The skill requires a valid GitHub session.

Help me troubleshoot the Hermes GitHub skill not appearing.

Your Hermes Agent is now fully equipped with an LLM brain and GitHub access. Next up, you will connect to a real open-source repository and have Hermes fetch and prioritize its issues.

Connect to a Target Repository and Fetch Issues

Your environment is ready. Now it is time to point Hermes at a real open-source project and see what it can do with actual GitHub issues.

To test autonomous issue resolution, Hermes needs a repository where it can push branches and open pull requests. You will fork a public project to your own account so Hermes can safely experiment without affecting the upstream codebase.

In this step, get ready to:
  • Fork and clone a target open-source repository.
  • Have Hermes fetch and prioritize open issues.
  • Test a single end-to-end issue resolution with Hermes.
Fork and clone a target open-source project

A fork is your personal copy of someone else's repository on GitHub. Hermes needs a fork so it can push fix branches and open pull requests without needing write access to the original project.

  • Pick an open-source repository on GitHub that has open bug issues. Good candidates are active projects with labels like bug, good first issue, or help wanted.
  • Fork the repository and clone it locally in one command by running:
gh repo fork [[TARGET_REPO="owner/repo-name"]] --clone

What does this command do?

The gh repo fork command creates a copy of the repository under your GitHub account. The --clone flag immediately clones that fork to your local machine so you have the code ready to work with.

GitHub CLI automatically sets up the original repository as an upstream remote and your fork as origin. This means Hermes can push branches to your fork and open PRs that reference the original project.

  • Confirm the fork was created and cloned by running:
gh repo list --fork --limit 5

You should see your newly forked repository listed in the output.

Use Hermes to fork instead

You can also do this inside a Hermes chat session. Start a session with hermes and type a prompt like: "Fork the repository owner/repo to my GitHub account, then clone my fork to /workspace/repo". Hermes will use the GitHub skill to handle it for you.

Fork command failing?

Make sure you are authenticated with GitHub CLI. Run gh auth status to verify your login is active.

If you see a "repository already exists" error, you may have already forked this project. Run gh repo clone your-username/repo-name to clone your existing fork instead.

help me troubleshoot why my gh repo fork command is failing

Ask Hermes to fetch and prioritize issues

Now that you have the repository locally, you need Hermes to scan the open issues and find the most actionable ones. Hermes uses the GitHub skill and gh issue list under the hood to fetch, filter, and rank issues by priority labels.

  • Start a Hermes interactive session by running:
hermes

You will see a welcome banner showing your model, available tools, and loaded skills.

  • Type the following prompt into your Hermes session to fetch and prioritize issues:
List the open issues on [[TARGET_REPO="owner/repo-name"]] sorted by priority. Look for labels like "bug", "priority:high", "good first issue", or "help wanted". Show me the top 5 most actionable ones with their numbers and descriptions.

What happens when you send this prompt?

Hermes reads your prompt, recognizes it involves GitHub, and uses the GitHub skill's terminal tool to run gh issue list with relevant filters. It then processes the results and presents a prioritized summary.

The agent looks for specific labels that signal actionable issues. You will see a numbered list of issues ranked by how feasible they are for an automated fix.

Hermes will display 5 issues with their numbers, titles, labels, and descriptions. Take note of one issue that looks like a straightforward bug fix.

Hermes not finding issues?

If the repository has very few or no labeled issues, try a different project. Look for repositories with at least 10 open issues and active use of labels.

If Hermes says it cannot access the repository, confirm your GITHUB_TOKEN is forwarded to the terminal backend. Run hermes doctor to check for configuration issues.

help me figure out why Hermes cannot list issues from my GitHub repository

Test a single issue resolution manually

Before you automate anything, it is important to see Hermes resolve one issue end-to-end. This confirms everything works and gives you a mental model of what the automated pipeline will do at scale.

  • In your existing Hermes session, type the following prompt to attempt a full resolution of one issue:
Take issue #[[ISSUE_NUMBER="issue number from the list above"]] from [[TARGET_REPO="owner/repo-name"]]. Read the issue description, reproduce the bug in the workspace, propose a fix, run the existing tests, and if they pass, create a new branch and commit the fix. Then open a pull request against my fork with the fix.

What does Hermes do with this prompt?

Hermes breaks the task into stages: it reads the issue from GitHub, navigates the cloned repository, attempts to reproduce the bug, writes a fix, runs the project's test suite, and (if tests pass) commits to a new branch named fix/issue-<number>.

Finally, it uses gh pr create to open a pull request against your fork. You can watch each step happen in real time as Hermes requests tool approvals.

This process may take a few minutes. Watch as Hermes works through reading the issue, exploring the code, writing a fix, and running tests.

  • Once Hermes finishes, verify the pull request exists by running:
gh pr list --repo [[YOUR_FORK="your-username/repo-name"]]

You should see at least one open pull request with a branch name starting with fix/issue-.

No pull request appeared?

If Hermes could not reproduce the bug, it may have reported back without creating a PR. Try a different issue that has clearer reproduction steps.

If the tests failed, Hermes may have skipped the commit. Check the session output for error messages. You can also try an issue labeled good first issue for a simpler starting point.

If you see a permission error, confirm your fork is set as the origin remote. Run git remote -v inside the cloned directory to check.

help me understand why Hermes did not open a pull request after attempting to fix an issue

You have just seen an AI agent read a real bug report, reproduce it, write a fix, validate it against the test suite, and open a pull request. Next up, you will automate this process so Hermes does it on a schedule without any manual prompting.

Create a Scheduled Cron Automation for Issue Sweeps

In the previous step, you proved that Hermes can resolve a single issue end-to-end. The manual process works, but open-source repos accumulate issues faster than one session can handle.

In this step, you will set up a cron job that runs every four hours, sweeps the repo for priority issues, and delegates each one to a parallel subagent. Instead of manually asking Hermes to fix issues one at a time, the automation handles the full cycle unattended.

In this step, get ready to:
  • Create a cron job that periodically fetches and prioritizes open issues.
  • Verify the job is registered and trigger it manually for testing.
  • Monitor delegate subagents as they work on issues in parallel.
Create a cron job that sweeps issues by priority

Hermes cron jobs run in fresh agent sessions with their own context. The prompt you provide must be completely self-contained because the job has no memory of your current chat.

  • Create the scheduled automation by running this command in PowerShell:
hermes cron create "0 */4 * * *" "Go through the open issues on [[TARGET_REPO="owner/repo"]] with labels 'bug' or 'help wanted'. For each of the top 3 highest-priority issues that don't already have an open PR: 1. Create a delegate subagent for each issue 2. Each delegate should: clone my fork, create a branch named fix/issue-<number>, read the issue, attempt to reproduce, write a fix, run tests, commit if tests pass, and open a PR 3. Work on all 3 issues in parallel using delegate_task 4. Report back which issues were successfully fixed and which failed" --name "issue-resolver" --deliver local

What does this command do?

The 0 */4 * * * schedule means "run at minute 0 of every 4th hour" (six times per day).

The prompt tells Hermes to fetch issues labeled bug or help wanted, skip any that already have PRs open, and spin up parallel delegates for the top 3. Each delegate independently clones, branches, reproduces, fixes, tests, and opens a PR.

The --deliver local flag saves the job's output to a local file instead of sending notifications. The --name flag gives the job a human-readable identifier you can reference later.

Why cron instead of running Hermes manually?

Manual sessions require you to be at the keyboard. A cron job runs unattended on a schedule, so issues get triaged and fixed even while you sleep.

Hermes spins up a fresh agent session for each run, keeping context clean and token usage efficient. Each cron run uses delegate_task to spawn up to 3 concurrent subagents that work in parallel, each with their own isolated terminal session.

After running the command, Hermes confirms the job was created and shows you the job ID.

Getting an error about schedule format?

Make sure the schedule string "0 */4 * * *" is quoted and has exactly five fields separated by spaces.

Hermes supports standard 5-field cron expressions. Natural language like "daily at 9am" is not supported. Double-check you have no extra spaces or missing asterisks.

help me fix my cron schedule syntax

Verify the cron job is registered and test it

Before waiting four hours for the schedule to fire, confirm the job exists and trigger it manually to watch the delegates in action.

  • List all registered cron jobs by running:
hermes cron list
  • Confirm that issue-resolver appears in the output with the schedule 0 */4 * * * and delivery target local.

Job not showing up in the list?

If hermes cron list shows no jobs, the create command may have failed silently. Re-run the hermes cron create command and check for error output in the terminal.

Make sure the prompt string is wrapped in double quotes and the --name and --deliver flags come after the closing quote of the prompt.

help me figure out why my cron job did not register

  • Trigger the job immediately for testing by running:
hermes cron trigger issue-resolver

What does this command do?

The trigger subcommand fires the named job immediately without waiting for the scheduled time. Hermes accepts job names (case-insensitive) in place of hex IDs for convenience.

This is equivalent to the schedule firing naturally. Hermes spins up a fresh session, reads your prompt, and begins executing the issue resolution workflow with parallel delegates.

  • Watch the terminal output. You should see Hermes acknowledge the trigger and begin spawning delegate subagents for the top issues.
Monitor delegate execution

Once the cron job fires, Hermes spawns up to 3 parallel subagents. Each one independently clones the fork, creates a branch, and attempts to fix its assigned issue.

  • Check the status of the running delegates by typing this in your Hermes chat session:
Show me the status of the running delegates

What should I see?

Hermes shows a summary of each subagent's progress, including which issue it is working on and what stage it has reached (cloning, reproducing, fixing, testing, or opening a PR).

Each subagent gets its own terminal session. If you chose the Docker backend, all delegates share the same persistent container but operate in separate working directories.

  • Wait for the delegates to complete. Each successful delegate opens a PR on your fork. Failed delegates report what went wrong.
  • Verify any new pull requests by running:
gh pr list --repo [[YOUR_FORK="your-username/repo"]]
  • You should see new pull requests with branch names matching the pattern fix/issue-<number> for each issue the delegates successfully resolved.

Delegates not spawning or timing out?

Confirm your xAI Grok OAuth provider is still connected by running hermes doctor. If the provider shows disconnected, re-authenticate with hermes model.

If using the Docker backend, ensure Docker Desktop is running. Delegates share the same persistent container, so a stopped Docker service blocks all subagent terminal access.

The Secret Mission later adds intelligent filtering to skip overly complex issues that delegates cannot complete in time.

help me debug why my delegates are not running

Your automated issue resolver is now registered and tested. Next up, you will set up a GitHub webhook so Hermes reacts instantly to new issues the moment they are created.

Set Up a GitHub Webhook for Real-Time Issue Response

Your cron job sweeps issues every four hours. That works for batch processing, but what about issues that need attention right now?

In this step, you will set up a GitHub webhook that triggers Hermes the instant a new issue is opened. Instead of waiting for the next cron cycle, Hermes receives an event in real time, assesses the issue, and either spawns a delegate to fix it or posts a comment requesting more details.

In this step, get ready to:
  • Subscribe Hermes to GitHub issue events via a webhook.
  • Register the webhook endpoint on your GitHub fork.
  • Test the full pipeline by creating a test issue and watching Hermes respond.
Subscribe to GitHub issue events

Hermes supports dynamic webhook subscriptions that listen for specific GitHub events and trigger an agent run when one arrives. You will create a subscription named github-issues that listens for issue events and instructs the agent to assess, fix, or request more information.

  • Create the webhook subscription by running this command in PowerShell:
hermes webhook subscribe github-issues --events "issues" --prompt "New GitHub issue received: Repository: {repository.full_name} Issue #{issue.number}: {issue.title} Author: {issue.user.login} Action: {action} Body: {issue.body} Labels: {issue.labels} If action is 'opened' or 'labeled' with a priority label: 1. Assess if this issue is reproducible from the description 2. If yes, create a delegate to: clone the fork, create branch fix/issue-{issue.number}, reproduce the bug, write a fix, run tests, and open a PR 3. If the issue is too vague to reproduce, post a comment asking for reproduction steps If action is not 'opened' or not a priority label change, respond with [SILENT]." --deliver github_comment

What does this command do?

  • hermes webhook subscribe github-issues creates a new dynamic webhook route named github-issues.
  • --events "issues" filters incoming payloads to only accept GitHub issue events.
  • --prompt defines the template Hermes uses when the event arrives. Payload fields like {issue.number} and {action} are replaced with real values from the GitHub event.
  • --deliver github_comment tells Hermes to post its response as a comment on the issue itself.
  • The [SILENT] keyword instructs Hermes to ignore events that are not relevant (like issue closures or edits).
  • After running the command, Hermes prints a webhook URL and an HMAC secret. Copy the webhook URL and save it somewhere. You will need it in the next substep.

Save the HMAC secret too

The HMAC secret is shown only once. You can optionally use it when registering the webhook on GitHub for payload signature verification. For this project, the auto-generated secret is sufficient.

  • Verify the subscription was created by running:
hermes webhook list

You should see github-issues in the list with its URL, events, and delivery target.

Webhook platform not enabled?

If Hermes prints setup instructions instead of creating the subscription, the webhook platform is not enabled. Run hermes gateway setup to configure it, then retry the subscribe command.

help me enable the Hermes webhook platform

Configure the webhook on your GitHub fork

The Hermes subscription creates a local listener, but GitHub does not know about it yet. You need to register a webhook on your fork that points to the Hermes webhook URL.

What if I'm running locally?

If Hermes is running on your local machine, the webhook URL is not reachable from the internet. You need a tunnel to expose it.

Use a tool like ngrok or cloudflared to forward traffic from a public URL to your local Hermes port (default 8644). Copy the public URL the tunnel provides and use that as your webhook URL in the next command.

  • Register the webhook on your GitHub fork by running:
gh api repos/[[GH_USERNAME="your-github-username"]]/[[REPO_NAME="your-repo-name"]]/hooks --method POST --field "name=web" --field "config[url]=[[WEBHOOK_URL="your-hermes-webhook-url"]]" --field "config[content_type]=json" --field "events[]=issues"

What does this command do?

  • gh api repos/.../hooks --method POST calls the GitHub REST API to create a new webhook on your repository.
  • name=web is the required webhook type for standard HTTP webhooks.
  • config[url] is the Hermes webhook URL that GitHub will POST events to.
  • config[content_type]=json tells GitHub to send the payload as JSON.
  • events[]=issues subscribes to issue events only.

You should see a JSON response with an id field and "active": true. This confirms the webhook is registered and active.

Getting a 404 or 403 error?

A 404 means the repository path is wrong. Double-check you are using your own username and the exact repo name (case-sensitive).

A 403 means your GitHub token does not have webhook permissions. Run gh auth refresh -s admin:repo_hook to add the required scope, then retry.

help me fix GitHub webhook registration errors

Test the webhook by creating a test issue

Everything is wired up. Time to verify the full loop by creating a test issue on your fork and confirming that Hermes receives the event and responds.

  • Create a test issue on your fork by running:
gh issue create --repo [[GH_USERNAME="your-github-username"]]/[[REPO_NAME="your-repo-name"]] --title "Test: Button click handler fails on empty input" --body "Steps to reproduce: 1. Click submit with empty form 2. Expected: validation error 3. Actual: unhandled exception" --label "bug"

What happens next?

GitHub sends an issues event (action: opened) to your Hermes webhook URL. Hermes receives it, formats the prompt with the issue details, and starts an agent run.

The agent assesses if the bug is reproducible. If yes, it spawns a delegate subagent that clones the fork, creates a branch named fix/issue-<number>, attempts the fix, and opens a PR. If the issue description is too vague, it posts a comment asking for reproduction steps.

  • Wait 1-2 minutes, then check your fork on GitHub.
  • Open the test issue you just created. You should see either a new comment from Hermes (requesting more details or confirming the fix) or a new pull request linked to the issue.

No response on the issue?

Check that your tunnel is still running (if using ngrok or cloudflared). Tunnels can disconnect after inactivity.

Verify the webhook delivery on GitHub. Go to your fork's Settings page, click Webhooks, select the webhook you created, and check Recent Deliveries. A green checkmark means GitHub delivered successfully. A red X means the endpoint was unreachable.

You can also run hermes webhook test github-issues to send a test POST and verify the route is working locally.

help me debug why Hermes is not receiving my GitHub webhook

Your automation now responds to issues in real time. In the Secret Mission, you will add intelligent filtering so Hermes skips issues that are too complex for autonomous resolution.

Secret mission

Add Intelligent Issue Filtering with Grok

Your automation currently throws resources at every issue it finds. But what if an issue requires an architectural overhaul that no single subagent can handle? In this secret mission, you'll add an AI-powered triage layer that rates issue complexity before committing resources, skipping issues that are too large for autonomous resolution.

Clean Up Your Resources

Clean Up Your Resources

This project runs on your local machine and uses your existing X subscription for Grok API calls. There are no additional ongoing costs beyond what you already pay for SuperGrok or X Premium+.

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

Resources you used:

  • Hermes cron job (smart-issue-resolver).
  • Hermes webhook subscription (github-issues).
  • GitHub fork of the target repository.
  • Local workspace files (/workspace/<repo> and /workspace/.hermes-context.md).
  • Docker container for sandboxed execution (~1-2GB disk, if Docker backend was chosen).
  • GitHub CLI (gh).

Keep everything running

No action needed. Choose this if you want Hermes to keep sweeping issues and responding to webhooks automatically.

  • Your X subscription covers the Grok API calls. There are no additional charges.
  • Monitor your automations at any time by running hermes cron list.
  • The webhook stays active as long as the Hermes gateway is running.
  • The Docker container persists between sessions and reuses the same ~1-2GB of disk space (if Docker backend was chosen).
  • GitHub CLI remains installed and authenticated on your machine.

Pause - I'll come back to this later

Pause the cron job to stop scheduled runs while keeping everything configured for later.

  • Pause the cron job by running:
  • The webhook subscription remains registered, but Hermes only processes events when the gateway is running. Close Hermes to stop webhook-triggered runs.
  • Your fork, local files, and Docker container remain untouched.
hermes cron pause smart-issue-resolver

When you are ready to resume, run:

hermes cron resume smart-issue-resolver

Delete - I don't want to use this again

Remove all project automations and resources to start fresh.

  • Delete the cron job by running:
hermes cron delete smart-issue-resolver
  • Remove the webhook subscription by running:
hermes webhook remove github-issues
  • Delete your GitHub fork. First, authorize the delete scope, then delete the repository:
gh auth refresh -s delete_repo
gh repo delete <your-username>/<repo> --yes
  • Remove the local workspace files by running:
rm -r /workspace/<repo>
rm /workspace/.hermes-context.md
  • The Docker container auto-cleans when Hermes shuts down. No manual removal needed.
  • Uninstall GitHub CLI by running:
winget uninstall --id GitHub.cli

That's a Wrap!

That's a Wrap!

Nice work! You've just built a fully autonomous issue resolution pipeline powered by Hermes Agent and xAI Grok.

Your system monitors a real open-source repository, triages issues by complexity, reproduces bugs in a sandboxed environment, proposes fixes, and opens pull requests. All without you lifting a finger.

You've learned how to:

  • Configure Hermes Agent with xAI Grok OAuth and connect it to a real open-source GitHub repository using the GitHub skill and CLI.
  • Build a cron-based automation that periodically sweeps issues by priority and delegates resolution to parallel subagents that reproduce bugs, write fixes, run tests, and open pull requests.
  • Set up a GitHub webhook for real-time response to new issues, completing an end-to-end pipeline from issue creation to automated PR submission.
  • Secret Mission: Added intelligent complexity assessment so the agent skips issues too complex for autonomous resolution and explains why.

Ready to quiz yourself?