GitHub Ops

GitHub Operations

Deliver the requested GitHub state, not a successful-looking command. A 200, 201, 202, or 204 response is evidence that GitHub accepted a request; it is not proof that every requested field changed, an invitation was accepted, an asynchronous job finished, or the user's business outcome was achieved.

Route by operation

Read only the reference required for the task:

For local Git recovery, dirty worktrees, bundles, or lost commits, use git-safety-net. This skill owns GitHub-hosted state. For repository copies, also handle per-remote authentication and sync setup.

Universal operating contract

1. Classify the request before touching GitHub

• Answer, inspect, diagnose, or review: read-only. Do not create a PR, issue, comment, invitation, workflow run, or setting change.
• Create, change, merge, close, grant, revoke, publish, or delete: the named state change is authorized. Keep the target and blast radius inside that request.
• Destructive, public, credential-related, production-triggering, or externally communicative: require the exact target, consequence, and recovery path. If the user did not provide a material choice such as repository owner, visibility, or message content, stop before the write.

Do not turn a read-only investigation into a mutation because the fix looks obvious. Do not send a comment, review, issue, or invitation whose recipient or content was not authorized in the current task.

For an authorized contributor, assess repository access against their ongoing contribution role, not just today's read or sync command. Repository Write access and permission to update the default branch are separate decisions. Follow the user's chosen contribution scope; use branch protection and PR review to control integration rather than silently reducing a contributor to Read. A diagnosis alone still does not authorize a grant.

2. Bind identity, host, and target

Before the first write, verify the active account and resolve a fully qualified target:

gh auth status --hostname HOST
gh api --hostname HOST user --jq '.login'
gh repo view HOST/OWNER/REPO \
  --json nameWithOwner,visibility,isPrivate,viewerPermission,url

For github.com, OWNER/REPO is sufficient. Never use gh auth status --show-token for routine diagnosis, and never print, paste, or log a token.

Before the first push to a remote in the current session, read its live visibility:

gh repo view OWNER/REPO \
  --json nameWithOwner,visibility,isPrivate,stargazerCount,forkCount,url

Bind identity to the interface that will perform the write. CLI identity does not establish a connector, browser, REST client, or Git SSH identity. Resolve the expected actor from the user's authorized task; neither the repository owner nor an available credential selects that actor automatically. For connectors, use a read-only current-user operation from that same connector and confirm its actor. If that interface cannot expose the actor, use the already verified CLI channel for the authorized write; do not make a test comment to discover its identity.

For authorized gh API/hosted-state writes, use the bundled checked invocation. Resolve <github-ops-dir> to the directory containing this SKILL.md; run the helper by that path from the task's working directory. Its executable argument and rejection contract is checked_gh.py.

uv run python <github-ops-dir>/scripts/checked_gh.py --expected-login <EXPECTED_LOGIN> --host HOST
uv run python <github-ops-dir>/scripts/checked_gh.py --expected-login <EXPECTED_LOGIN> --host HOST -- pr edit <NUMBER> -R OWNER/REPO --title '<AUTHORIZED_TITLE>'

The first command is read-only. The second resolves the current credential, checks GET /user, and pins that same credential for one command. A mismatch or unknown actor exits before execution. It guards only gh, not connector calls, browser actions or Git pushes. Authentication/configuration commands are rejected; task authorization, exact targets and independent readback remain required. Supply -R OWNER/REPO for repository-scoped commands, or an explicit repository operand for gh repo. The wrapper qualifies that target with the checked host, removes inherited GH_REPO and alternate token variables from the child, and rejects conflicting host operands. Omit the command for an identity-only read. Organization secret/variable operations instead use their explicit --org scope; personal Codespaces secrets use --user. Body/title/field values remain unchanged even when they resemble flags or URLs. Public API absolute URLs use api.github.com; relative API endpoints remain supported. Switching account, credential, host or interface invalidates earlier identity evidence. Recheck before the next write; do not reuse a prior session's pass.

Reference examples show native gh operation syntax. Execute hosted-state mutations by passing those arguments after the helper's --, with an explicit repository or account scope; bare gh remains suitable for readback and separately authorized authentication/configuration. When a builtin's operand shape is rejected, use its supported explicit REST/GraphQL equivalent through the same helper; do not bypass the actor check. A failed or timed-out invocation does not prove the mutation was absent: read the exact target before retrying.

For incident attribution, preserve event ID/time, actor and interface separately from the ChatGPT execution account. A comment author's login and performed_via_github_app establish GitHub actor/application, not the ChatGPT email. A session's creator identity and today's auth file do not establish its historical execution account. Keep missing links unknown.

3. Read current authority and preview the delta

Use GitHub-hosted state, not a stale local ref or remembered setting. Capture only the fields required to prove the requested transition. Before a consequential write, make this plan explicit:

Target: fully qualified repository, organization, PR, issue, run, or account
Current: authoritative fields and immutable IDs/SHAs
Requested: exact field or state transition
Blast radius: people, repositories, forks, runs, or public surfaces affected
Recovery: exact inverse operation or explicit “not recoverable”
Readback: independent GET/CLI query and expected result

If the user already authorized this exact consequence, execute it. Do not add a ceremonial second confirmation. If target, scope, public exposure, deletion, recipient, or recovery remains ambiguous, pause before the write.

4. Choose an interface whose input contract actually supports the change

Prefer, in order:

1. a purpose-built gh subcommand;
2. a documented REST endpoint for one resource or authoritative readback;
3. GraphQL when the required mutation/query is GraphQL-only or combines related data;
4. the documented GitHub UI when the setting has no supported API input.

Response fields are not automatically writable fields. Before using PATCH, compare the desired key against the operation's current request body parameters, not the shape returned by GET. GitHub may ignore an unsupported key while still returning a successful response. Do not switch API families merely to make the command run.

Use explicit methods with gh api. Adding -f or -F changes the default method to POST; filtered GET requests must include -X GET.