gh-oss-go-bump

name	gh-oss-go-bump
license	MIT
description	Bump Go version across multiple OSS repositories. Use when the user wants to update Go across repos, says "bump go version", "update go", "go version bump", "upgrade go", or mentions updating Go in their projects. Also triggers on "go 1.x", "latest go", "go security update", "/go-bump".
argument-hint	[<go-version>]
compatibility	Requires gh CLI, gh oss-watch extension, and Go toolchain installed locally
metadata	{"author":"jackchuka","scope":"generic","layer":"workflow","confirms":["create PRs","merge PRs"]}

Go Version Bump

Batch workflow for bumping Go versions across multiple OSS repositories. Follows the three-phase pattern: discover and investigate, test locally, then create PRs — with user confirmation gates before every irreversible action.

Step 1: Discover Go Repos and Latest Go Version

Run these two commands in parallel:

1. List Go repos:

   gh oss-watch list
   

   Filter to repos where the language column is "Go".

2. Find latest Go version: Web search for the latest stable Go release. Identify both the latest minor (e.g., 1.26) and latest patch (e.g., 1.26.1).

Present findings to the user:

• Number of Go repos found
• Latest stable Go version
• Key highlights of the new version (security fixes, notable features)

Step 2: Investigate Each Repo (parallelize if possible)

For each Go repo, dispatch one agent to check:

1. Current Go version — fetch go.mod via gh api repos/<owner>/<repo>/contents/go.mod
2. CI version strategy — check if workflows use go-version-file: go.mod or hardcoded versions
3. Open PRs/issues — check for conflicts with gh pr list and gh issue list
4. Test coverage — check for presence of _test.go files
5. Deprecated patterns — scan for io/ioutil, reflect.SliceHeader, or other patterns removed in the target Go version

Each agent returns a structured assessment: repo name, current version, CI strategy, has tests, safe-to-bump verdict, and any concerns.

Present Investigation Summary

Show a table to the user:

| Repo | Current Go | CI Strategy | Has Tests? | Safe? | Notes |
|------|-----------|-------------|-----------|-------|-------|

Flag any repos with:

• Large version jumps (2+ minor versions)
• Old dependencies that may need updating
• Hardcoded Go versions in CI (requires extra file changes)
• No tests (higher risk)

Ask the user to confirm which repos to proceed with before moving to Step 3.

Step 3: Test Locally (parallelize if possible)

After user confirms the repo list, dispatch one agent per repo. Each agent:

1. Clones the repo to /tmp/go-bump/<repo-name>
2. Edits go.mod to set the new Go version
3. Runs go mod tidy
4. Runs go test ./...
5. Reports: success/failure, any test output, any dependency changes from tidy

Important: these are local-only operations — no branches pushed, no PRs created. This phase is purely for verification.

Present Test Results

Show a results table:

| Repo | Old → New | mod tidy | tests | verdict |
|------|-----------|----------|-------|---------|

If any repo fails:

• Show the failure details
• Suggest whether it's fixable (e.g., dependency needs updating) or should be skipped
• Let the user decide

Ask the user to confirm before creating PRs. This is the last gate before irreversible actions.

Step 4: Create PRs (parallelize if possible)

Only after explicit user confirmation. Dispatch one agent per repo using the already-cloned repos in /tmp/go-bump/. Each agent:

1. Creates branch chore/bump-go-<version> (e.g., chore/bump-go-1.26.1)
2. Stages go.mod and go.sum
3. Commits: chore: bump Go version from <old> to <new>
4. Pushes with -u flag
5. Creates PR via gh pr create:
   • Title: chore: bump Go version to <new>
   • Body includes: version change, key improvements (security fixes, performance), and local test results

Each agent returns the PR URL.

Present PR Summary

Show all created PRs in a table:

| Repo | PR URL |
|------|--------|

Step 5: Merge (only if user explicitly requests)

Never auto-merge. Only proceed when the user explicitly asks to merge.

Check CI First

gh pr checks <number> --repo <owner>/<repo>

Present CI status for all PRs. If any are still running, wait and re-check.

Merge

After all checks pass and user confirms:

gh pr merge <number> --repo <owner>/<repo> --squash --delete-branch

If --squash fails (repo settings), try --merge. If that also fails, try --rebase.

Present final status table showing all merged PRs.

Step 6: Cleanup

After all PRs are merged (or the workflow is done):

rm -rf /tmp/go-bump/

Confirmation Gates

This workflow has three user confirmation points before irreversible actions:

Gate	Before	Why
Gate 1	Local testing (Step 3)	User reviews investigation and chooses which repos to test
Gate 2	PR creation (Step 4)	User reviews test results before any pushes to remote
Gate 3	Merging (Step 5)	User reviews CI status before merging to main

Never skip these gates. If the user says "do everything", still present the investigation summary (Gate 1) — but you may proceed through Gates 2 and 3 without pausing if the user explicitly asked for full automation.

Key Principles

• Maximize parallelism — investigate, test, and create PRs concurrently across repos
• Test before pushing — always verify locally with go mod tidy and go test ./...
• Confirm before irreversible actions — PRs and merges require explicit user approval
• Skip gracefully — if a repo fails testing, skip it and continue with the rest
• Clean up — remove /tmp/go-bump/ clones when done
• Detect merge strategy — repos may require squash, merge, or rebase; try squash first