GitHub Collaboration Workflow
Purpose
Own the collaboration layer around a change: pull requests, review and comment
triage, issue linkage, CI status, and durable handoffs. Keep local Git,
GitHub-settings, and release operations with their focused owners.
Workflow
- Confirm the exact repository, branch, base branch, current
git status,
remote visibility, and gh authentication before a remote action.
- Read repository contribution and review policy. Inspect existing pull
requests and issues before creating duplicates.
- Prepare a PR only after the change is committed, validated proportionately,
and pushed with explicit authority. Use a concise body that explains intent,
risk, and verification; link the governing issue when one exists.
- Inspect CI checks, reviews, and unresolved comments as separate gates. Name
failures, requested changes, and unknown states precisely.
- Address valid review feedback in the owning branch; route broader follow-up
to the repository's roadmap or issue system. Re-read the changed thread and
checks before reporting it resolved.
- For an external wait, do one bounded snapshot. Use the host's supported
continuation mechanism no sooner than five minutes later; do not keep a
shell watch or poll loop running.
- Merge, label, close, reopen, or delete remote work only with explicit
authority or a repository-owned release contract. Verify the resulting
GitHub state after each mutation.
Boundaries
- Route local branch, commit, rebase, conflict, and recovery work to
git-workflow.
- Route GitHub server settings, rulesets, and security configuration to
maintain-github-repository.
- Route protected-main release PRs, tags, releases, and branch-accounting
cleanup to
maintain-project-repo.
- Keep credentials, private issue content, and security findings out of public
PR bodies and reports.
Hermes Notes
This is portable guidance. Verify gh availability and authentication before
remote actions. On a pending CI or review gate, Hermes uses a self-contained
cronjob delivered to the origin session with attach_to_session=true; the
packet must include repository, branch, PR, commit, gate, and safe inspection.
1---2name: github-collaboration-workflow3description: Prepare and maintain GitHub pull requests, reviews, issues, CI triage, and durable handoffs. Use for collaboration work after local Git changes exist; not for GitHub settings or release publication.4---56# GitHub Collaboration Workflow78## Purpose910Own the collaboration layer around a change: pull requests, review and comment11triage, issue linkage, CI status, and durable handoffs. Keep local Git,12GitHub-settings, and release operations with their focused owners.1314## Workflow15161. Confirm the exact repository, branch, base branch, current `git status`,17 remote visibility, and `gh` authentication before a remote action.182. Read repository contribution and review policy. Inspect existing pull19 requests and issues before creating duplicates.203. Prepare a PR only after the change is committed, validated proportionately,21 and pushed with explicit authority. Use a concise body that explains intent,22 risk, and verification; link the governing issue when one exists.234. Inspect CI checks, reviews, and unresolved comments as separate gates. Name24 failures, requested changes, and unknown states precisely.255. Address valid review feedback in the owning branch; route broader follow-up26 to the repository's roadmap or issue system. Re-read the changed thread and27 checks before reporting it resolved.286. For an external wait, do one bounded snapshot. Use the host's supported29 continuation mechanism no sooner than five minutes later; do not keep a30 shell watch or poll loop running.317. Merge, label, close, reopen, or delete remote work only with explicit32 authority or a repository-owned release contract. Verify the resulting33 GitHub state after each mutation.3435## Boundaries3637- Route local branch, commit, rebase, conflict, and recovery work to38 `git-workflow`.39- Route GitHub server settings, rulesets, and security configuration to40 `maintain-github-repository`.41- Route protected-main release PRs, tags, releases, and branch-accounting42 cleanup to `maintain-project-repo`.43- Keep credentials, private issue content, and security findings out of public44 PR bodies and reports.4546## Hermes Notes4748This is portable guidance. Verify `gh` availability and authentication before49remote actions. On a pending CI or review gate, Hermes uses a self-contained50`cronjob` delivered to the origin session with `attach_to_session=true`; the51packet must include repository, branch, PR, commit, gate, and safe inspection.
gaelic-ghost