GitHub integration: standardize on go-github API for platform ops, git for content

[antoinetoussaint-byte]

Summary

We interact with GitHub through three different mechanisms today — the gh CLI, raw git, and the go-github API — with no clear rule for which to use. This umbrella tracks aligning on a single principle and migrating the mismatched call sites.

Guiding principle

Use git for git operations; use the go-github API for GitHub platform operations. The gh CLI is only a thin API wrapper in a subprocess — it adds a runtime binary + auth dependency and inconsistent error handling for no benefit over the API client we already vendor.

• Content operations (clone / add / commit / tag / push / ls-remote / ls-files) → git binary. The REST API is slower and lossier here; reimplementing git over HTTP is a step backwards. Keep as-is.
• Platform operations (create repo / release / upload asset / PR / issue) → go-github. These are not git; they're API calls currently shelled through gh.

Key fact: no new dependency

github.com/google/go-github/v89 is already a direct dependency (go.mod:22), used read-only today in cmd/agents/versions.go (newGitHubClient :488, ListReleases/ListTags). Token plumbing already exists in githubToken() (:500): GITHUB_TOKEN / GH_TOKEN, falling back to gh auth token (credential-only use of gh, which is fine).

Suggested first step: lift newGitHubClient + githubToken into a shared pkg/github helper so every migration reuses one client + token path.

Where each mechanism is used today

Area	File(s)	Mechanism	Keep / migrate
librarystore content push	pkg/librarystore/github.go	raw git	keep (git op)
librarystore repo creation	(missing — errors at github.go:135)	none	migrate → API (#459)
Agent release + asset upload	cmd/publish/agent_release.go (:291,:319,:51)	gh CLI	migrate → API (#457)
GitOps PRs	pkg/gitops/publish.go (:1208–:1250), observe.go:726	gh CLI	migrate → API (#458)
Chore "core behind" issue	cmd/status/release.go:266	gh CLI	migrate → API (#458)
GitOps branch pushes	pkg/gitops/{publish,observe,remote}.go	raw git	keep (git op)
Release tags	cmd/publish/release.go	raw git	keep (git op)
Version listing	cmd/agents/versions.go	go-github ✅	already correct

Work items

• Migrate agent-release publishing from gh CLI to go-github API #457 — Migrate agent-release publishing from gh CLI to go-github (highest value — drops the hard gh binary requirement from releases)
• Migrate GitOps PR + chore-issue flows from gh CLI to go-github API #458 — Migrate GitOps PR + chore-issue flows from gh CLI to go-github
• librarystore: auto-create library repo via go-github API (keep git for content) #459 — librarystore: auto-create the library repo via go-github (close the "repo must exist" gap)
• (implied by the above) extract shared pkg/github client/token helper

Non-goals

• Moving any git content operation (push/tag/commit) to the REST API.
• Removing the gh auth token credential fallback — that's a convenience, not a hard dependency.
• pip/npm library publishing — tracked under the library-publishing epic (Epic: durable versioned library publishing — storage abstraction for go get / pip / npm #446).

[antoinetoussaint-byte]

Completed on main. The umbrella "git for content, go-github for platform ops" migration shipped as three PRs, one per sub-issue:

• feat: publish agent releases via go-github instead of gh CLI (#457) #462 — agent-release create + asset upload (closed Migrate agent-release publishing from gh CLI to go-github API #457)
• refactor: migrate GitOps PR + chore-issue flows to go-github (#458) #463 — GitOps promotion PR + chore-issue flows (closed Migrate GitOps PR + chore-issue flows from gh CLI to go-github API #458)
• feat: auto-create library repo via go-github in librarystore (#459) #461 — librarystore auto-create-repo (closed librarystore: auto-create library repo via go-github API (keep git for content) #459)

Shared client/token/owner plumbing lives in pkg/gh. Deliberately kept on gh: pkg/gitops/observe.go still reads reviewDecision via gh pr view — a GraphQL-only field with no go-github REST equivalent; deriving it from REST review lists would weaken the promotion security gate. The gh auth token credential fallback also stays by design.

(The consolidation PR #464 was closed as superseded — its work had already landed via the three PRs above.)