Small, low-risk work can stay simple.
The status card can continue straight to Start Codex session or the selected coding agent.
Flagship lane
Executor-ready handoff
Use this lane when coding or implementation may be needed, but Hermes should first prepare a reviewable handoff. The user can choose Codex, Claude Code, another executor, an oh-my runtime, or Hermes coding skills.
Handoff lifecycle
"Turn this issue into a PR" should become scope, non-goals, acceptance criteria, verification commands, review expectations, and executor choice before anyone claims code changed.
request
plan accepted
executor choice
dispatch
observed evidence
Workspace first
Before a wrapper opens Codex, Claude Code, an oh-my runtime, or a
Hermes coding path, OMH can prepare a
worktree_session_isolation/v1 plan. It keeps workspace
risk visible, then lets the wrapper invoke an explicit local worktree
creator when isolation is selected.
Risky or multi-file work gets a pause.
The first button becomes Prepare worktree; the backend can create the Git worktree before Hermes starts the coding session.
Parallel, team, or swarm work needs isolation.
OMH records worktree creation as workspace evidence only; executor progress still needs separate runtime evidence.
Hermes coding harness
When the user chooses Hermes itself as the coding owner, OMH adds a
read-only hermes_coding_harness/v1 view. It does not
launch workers or create PRs. It tells the wrapper which stage is
current, which lane owns the next step, and which evidence is still
missing.
intake
plan
build
verify
review
PR prep
Use cases
Make this GitHub issue PR-ready.
Hermes prepares the smallest reviewable unit and hands it to the selected executor, runtime, or Hermes coding owner after acceptance.
Some people use Codex, others use Claude Code.
OMH keeps the handoff executor-neutral and lets the wrapper ask for selection when needed.
We want AI coding but need proof of what happened.
Status stays split across prepared, dispatched, executed, verified, reviewed, CI, and merge-ready states.