Pull Requests

15.5. Pull Requests — Opening Structured PRs

Via the gh CLI, not via MCP

As stated in 11.2, GitHub is deliberately not in the MCP catalog — Hermes controls PRs directly via the gh CLI through the github/* skill set, stronger than an ordinary MCP server because it covers nearly all GitHub operations.

Worktrees guarantee a clean diff

Because a worktree by default branches from the latest remote tip (not an old local HEAD), the PR opened has a diff that reflects only the actual changes — not contaminated with commits that the main branch already had but the local clone has not picked up yet.

Automated triggers via webhooks — extending beyond manual operations

For a workflow you want to fully automate (for example: the agent automatically opens a PR when a cron job detects a periodic bug that needs fixing), combine hermes webhook subscribe to listen to GitHub events, or hermes cron for the agent to periodically check and propose PRs on its own.

Notes

• Always have the agent write a clear PR description: what problem is being solved, the approach taken, how it was tested — not just listing the changed files.
• For a PR going into a production repo, keep a human approval step before merging — Hermes can create the PR on its own, but the merge decision should always go through a human, especially if you do not yet fully trust the agent’s accuracy on that kind of task.
• With small, focused PRs (thanks to per-feature worktrees in 15.2), review will be much faster and more accurate than a big PR lumping together unrelated changes.