How to use a Righthand with Github

Keep the pull request and the release separate

Use Righthand with GitHub to prepare a pull-request handoff for an approved repository. The useful report identifies what awaits review and which evidence remains missing. A merged pull request proves a repository action; it does not by itself prove that a deployment is serving the change or that the resulting behavior works.

GitHub's pull-request reference distinguishes repository context, pull-request number, base branch, and head commit. Keep those details beside review and check evidence. A successful check for an earlier commit should not be attached to a newer revision as if it covers the same code.

Choose a read-only first workflow

Inspect GitHub's available tools in integrations. Confirm which pull-request, review, and check reads are exposed. If a needed operation is absent, use owner-supplied links or an approved browser review. Do not infer merge or deployment authority from a provider's API documentation.

Give the repository owner and name, target branch, included pull requests, and the team's required evidence. Exclude unrelated private repositories even when the account has access. Decide whether draft pull requests belong in the report and label them explicitly.

An illustrative engineering brief

At 10 AM America/Los_Angeles on Thursday, review open non-draft pull requests targeting development in the named repository. Produce a private handoff with PR URL and number, base branch, current head SHA, requested reviewers, available review decisions, and required checks tied to that SHA. Flag missing evidence and unresolved owner questions. Do not merge, push, or deploy. Send to me for engineering-lead review. Reconcile the included PR count and verify each reported check's commit identity.

This example is illustrative. The team's merge policy determines the required reviews and checks; the assistant should not invent an approval standard.

Define the result precisely

An example entry could say: “PR 42; current head differs from the last reviewed commit; required check evidence unavailable; reviewer must inspect the new revision.” This avoids describing a previously approved revision as approval of every later change.

Keep a proposed reviewer reminder separate from an actual notification. A report delivered privately is complete when the intended owner receives it and can open its sources. Posting comments or requesting reviews requires an explicit destination and authorized content.

Reconcile subsequent runs

Match pull requests by repository and number, then compare head SHAs and review evidence. A force-push can change the code under the same PR. Mark stale evidence rather than retaining a green label from the earlier revision.

An access failure can hide checks or reviews. Return incomplete coverage instead of declaring the PR ready. If merging is later authorized and supported, independently verify the merge result and leave deployment verification as a separate task.

Use Righthand connection permissions to keep repository authority narrow. Check pricing before assigning a recurring engineering handoff.