Github Pr Workflow — GitHub PR lifecycle: branch, commit, open, CI, merge
Github Pr Workflow — GitHub PR lifecycle: branch, commit, open, CI, merge
Finding
Denne side er vigtig, fordi den gør GitHub PR-livscyklussen til en Hermes-native arbejdsrutine i stedet for et løst manuelt udviklerflow.
What it is
Siden beskriver en bundlet Hermes-skill til at oprette branches, committe ændringer, pushe kode, åbne pull requests, overvåge CI, hente fejl-logs, rette CI-fejl og merge PRs. Den viser både den foretrukne `gh`-vej og en `git` + API-fallback. Den passer især til coding-agenter under Hermes, fordi den binder repo-arbejde, testplan, PR-status og merge-beslutning sammen i én standardprocedure.
Should we use it?
Use now. For Lisa’s Hermes+n8n+LangGraph mission bør Hermes eje PR-arbejdet, når agenten eller en coding-delegate laver kodeændringer. n8n skal ikke bygge parallel PR-logik, og LangGraph skal ikke bruges til almindelig GitHub PR-håndtering, medmindre der er behov for avanceret stateful multi-agent orkestrering. Denne skill giver en klar, auditérbar vej fra ændring til review og CI-verifikation.
Recommendation
Gør `github-pr-workflow` til standard-skill for alle Hermes-styrede repo-ændringer, hvor outputtet skal ende som en GitHub PR med testplan og CI-verifikation før merge.
Use now
- Når Codex, Claude Code, OpenCode eller Hermes selv laver repo-ændringer, der skal reviewes.
- Når en issue eller bugfix skal forbindes til en PR med `Closes #...`, `Fixes #...` eller tilsvarende sporbarhed.
- Når CI fejler, og Hermes skal hente logs, lave en afgrænset rettelse, pushe igen og verificere status.
- Når der arbejdes på Hermes Agent Info, n8n-workflows, LangGraph-komponenter eller andre kodebaser, hvor ændringer bør gå via PR i stedet for direkte main.
- Når der ønskes ensartede PR-bodies med Summary og Test Plan.
Do not use / wait
- Brug den ikke til public content-review uden kodeændringer; dér er en almindelig review- eller publishing-proces nok.
- Brug den ikke til direkte merge, hvis repoet kræver menneskelig godkendelse, deployment-vindue eller ekstern QA.
- Brug den ikke som n8n-triggerdesign; GitHub-webhooks bør håndteres via Hermes webhook subscriptions eller eksisterende GitHub-event flows.
- Vent med auto-merge, indtil branch protection, required checks og review-regler er tydeligt sat.
- Brug ikke fallback med token/API-kald, hvis GitHub-auth ikke er sikkert konfigureret og verificeret.
Public page note
`github-pr-workflow` viser, hvordan Hermes kan styre en sikker og sporbar PR-proces fra branch til CI og merge uden at afsløre private repositories, credentials eller interne logs.