From issue to PR: AI workflow with Overvy and Hermes

I’ve been running Overvy as a kanban board on top of my GitHub issues for a while now. It pulls issues from multiple organizations and repos into one board, so I can see everything that needs doing across all my projects in a single place. AI was already writing the code. The gap was the manual orchestration: picking up a ticket, feeding it to the agent, waiting for the result, creating the PR myself. Wiring Overvy to Hermes, an autonomous AI agent running on my home server, closed that gap.

Here’s the idea: a GitHub issue lands in Overvy, gets flagged as ready for AI, Hermes picks it up, researches the codebase, implements a fix, and opens a PR. The card moves to “In Review” and waits for a human to look at the code. That’s the whole loop. No cron jobs, no webhooks, no babysitting.

How a ticket moves through the system

Overvy mirrors GitHub issues from all your organizations and repos onto a single kanban board. Each issue lives in a lane: Ready, In Progress, In Review, or Done. The piece that makes the AI workflow possible is a flag on each card. When you mark a ticket as ready for AI, Overvy treats it differently. It knows an agent should pick this one up, not a human.

Hermes runs as a persistent agent on my home server. It has a kanban worker profile that polls the Overvy API for tickets in the “ready” lane flagged for AI. When it finds one, it spawns a worker. The worker gets the issue title, the description, the repo and issue number, and a predefined task pipeline: set up the repo, understand the issue, create a branch, implement the changes, push, open a PR.

The worker does not guess. It follows the pipeline encoded in the task. That means the quality of the output depends heavily on the quality of the issue body. A vague one-liner gives the agent almost nothing to work with. A clear spec with acceptance criteria produces much better results.

Once the worker is running, it clones or updates the repo, reads the issue for requirements, and explores the codebase to pick up patterns and conventions. Then it creates a branch using a consistent naming scheme, something like fix/15-short-description or feat/15-feature-name, and implements the changes. If the project has tests, it runs them.

After the implementation is done, Hermes commits, pushes, and opens a pull request that references the original issue. It moves the Overvy card to “In Review” and stops.

The agent never merges its own code. The review gate is mandatory. A human looks at the PR, requests changes if needed, and merges when ready. The agent’s job ends at the PR.

What works and what doesn’t

I’ve had the best results with tasks that are small and well-defined. Bug fixes with clear reproduction steps are ideal. The agent can trace through the code, find the issue, and patch it. Small features work too, as long as they don’t require design decisions. Adding an endpoint, changing a validation rule, that kind of thing. Content updates like blog posts, documentation, or config changes are basically free. Dependency bumps and single-file refactoring are in the same category.

Where it falls apart is anything involving judgment: architectural decisions, UX design, trade-offs between competing approaches. These still need a human in the loop. The agent can present options, but it should not be the one choosing.

The issue body does most of the heavy lifting. I’ve learned to write issues differently now. A title like “Fix the login bug” with no body used to be enough for me to pick up and figure out. The agent needs the steps to reproduce, what the expected behavior is, and any relevant context. It takes an extra minute to write but saves way more than that on the other side.

Setting it up

You need Overvy connected to your GitHub repos, Hermes running on a machine that stays on (a home server, VPS, or always-on desktop), and a kanban worker profile configured in Hermes.

The worker profile needs your Overvy API key to list and move issues, a GitHub token to push branches and create PRs, and the local paths to your repositories. Once that’s wired up, Hermes handles the rest. The dispatcher polls on its own schedule and spawns workers when tickets are flagged. Nothing else to configure.

This article came through the pipeline

I created a GitHub issue titled “Write an article about AI workflow with Overvy and hermes” with the body:

The workflow that we triggered by flagging this ticket as ready for ai is actually the workflow we should write an article about.

Overvy pulled it onto the board. I flagged it as ready for AI. Hermes picked it up, researched the issue, explored my blog’s article format, wrote this post, created the header image, and opened a pull request.

The PR is waiting for review right now. If you’re reading this, it got merged.

The real change

Before this workflow, small issues sat in my backlog for weeks. They weren’t urgent enough to context-switch into, so they just accumulated. Now they get a PR within minutes of being flagged.

The bar for “worth doing” dropped from “worth my focused attention” to “worth writing a clear description.” That’s a much lower bar. It means more bugs get fixed, more small features ship, and the backlog shrinks instead of growing.

If you’re curious, the Hermes kanban system is open source. Overvy is at overvy.com.