Hand It an Issue, Get Back a PR — A Hermes Agent Skill Looping Between Codex and Claude CodeCodeNote.net<br>Switch to light / dark version

Hand It an Issue, Get Back a PR — A Hermes Agent Skill Looping Between Codex and Claude Code<br>#hermes-agent#ai-agent#claude-code#codex#github#developer-experience#automation

Tadashi Shigeoka · Thu, July 23, 2026

Last time I wrote omh-pr-multi-review, a skill that has Claude Code and Codex independently review the same pull request (Reviewing a PR with Claude Code and Codex at Once). That automated a step that happens after a PR already exists.

This time I went upstream and automated everything from the issue to the PR. I added omh-issue-loop to oh-my-hermes, my collection of customizations for Hermes Agent (PR #6).

Usage is one URL: a GitHub issue. From there the agent implements, validates, reviews, fixes the findings, verifies again, and stops with a pull request a human can review. It does not merge. It does not close the issue.

I run this skill in my day-to-day development. What running it revealed is that my own time has moved somewhere else entirely. The second half of this post is about that.

I have kept running my daily work through this skill since first publishing it, closing the holes that surfaced as they showed up. This post reflects the current state. What running it for real taught me turned out to be more interesting than what I had reasoned out at design time, so that is in here too.

What the skill contains

That is the whole of it.

skills/omh-issue-loop/<br>├── SKILL.md # skill definition (the orchestration procedure)<br>├── agents/openai.yaml # display name and default prompt<br>└── references/<br>├── commit-signing-preflight.md # commit-signing preflight procedure<br>└── workflow-flowchart.md # workflow map and invariants<br>The previous skill, omh-pr-multi-review, shipped a Python script so the control flow lived in deterministic code. This one has no script at all: a SKILL.md describing the procedure in natural language, plus the two references it points to.

That is not a reversal, it reflects a different problem shape. Multi-model review was a branchless, side-effect-heavy straight line: switch checkout, invoke four CLIs in order, always restore. A deterministic script is the natural fit.

An issue implementation loop is not that. Validation commands differ per repository, what to do next depends on what the reviewers said, and whether it converges at all is unknown in advance. Scripting that means either hardcoding repository-specific assumptions or demanding an enormous config file. So I left the judgment with the agent and instead wrote the prohibitions and the limits precisely.

The orchestrator never implements

SKILL.md opens not with what to do but with what not to do.

Orchestrate the workflow only. Delegate working-tree implementation and fixes to Codex CLI and all independent review and behavior verification to Claude Code CLI. Keep every Git history, remote, pull-request, issue, CI, and review operation under exclusive orchestrator control. Never implement, fix, review, merge, close the issue, or widen scope in the orchestrating agent.

That separation is the core of the design, for two reasons.

First, having the author review its own work is worthless. When the same model in the same session reviews its own diff, it just ratifies its earlier judgment. Only by splitting lineages (Codex writes, Claude Code reviews) does the review become independent information.

Second, the moment the orchestrator starts touching code, state becomes untraceable. Allow “Codex almost got it, I will just fix this bit myself” and the record of who wrote what disappears. The evidence the PR eventually carries (the changes Codex authored, finding counts per reviewer) collapses right there.

The worker never orchestrates either

The third sentence of the quote above, the one reserving every Git, remote, pull-request, issue, CI, and review operation to the orchestrator, was added after publication. Running the skill showed that a one-sided separation does not hold.

Hand Codex a bare /goal and it reads that as an end-to-end delivery task. Reading the issue and implementing it is exactly what I wanted. Then it commits, pushes, opens a pull request, marks it ready, and watches CI to completion, all before a single one of the orchestrator’s review gates has run.

That is not Codex misbehaving. Given an issue and a /goal, reading the objective as “get this to a pull request” is a perfectly reasonable interpretation. I simply had not written down where its job ended.

So the responsibility boundary became its own section.

Treat Codex implementation and fix processes as working-tree workers, not autonomous issue owners.

A worker may read the issue snapshot handed to it by the parent and the repository instructions, edit only issue-scoped files, run the relevant local validation, and report. That is the whole list. All changes are left uncommitted, and no worker retrieves live...