committing-changes

name	committing-changes
description	Automates the full commit-to-merge workflow: creates a branch, commits, pushes, opens a PR, waits for CI, squash merges, and deletes the branch. Also handles creating new releases. Triggers on: commit, ship it, land changes, release, new release, cut a release.

Committing Changes

Automates the full git workflow from commit to merge in a single action.

Prerequisites

• gh CLI must be installed and authenticated
• Working directory must be a git repository with a GitHub remote
• There must be uncommitted or staged changes to commit

Workflow

Follow these steps in order. Stop and report errors at any step.

1. Pre-flight Checks

• Run make test (or go test ./...) to ensure all tests pass before proceeding
• Confirm there are changes to commit (git status)
• If no changes exist, stop and inform the user

2. Determine Branch Name and Commit Message

• Analyze the staged/unstaged changes to understand what was done
• Generate a branch name following the convention: feat/short-description or fix/short-description
• Generate a commit message following Conventional Commits: feat: ..., fix: ..., refactor: ..., docs: ..., test: ...
• Present the branch name and commit message to the user and ask for confirmation before proceeding

3. Update Documentation

• Review the changes being committed and determine if they affect user-facing behavior (new flags, changed output, new subcommands, etc.)
• If so, update README.md (and any other relevant docs) to reflect the changes
• If the changes are purely internal (refactors, test additions, CI changes), skip this step

4. Create Branch and Commit

git checkout -b <branch-name>
git add -A
git commit -m "<commit-message>"
git push -u origin <branch-name>

5. Create Pull Request

gh pr create --title "<commit-message>" --body "<pr-description>" --base main

• The PR body should summarize the changes concisely

6. Wait for CI

Before waiting, check the CI workflow path filters in .github/workflows/ci.yaml. If none of the changed files match the paths listed in the on.pull_request.paths filter, skip waiting and proceed directly to merge.

Otherwise, run scripts/wait-for-ci.sh to poll the CI status of the PR. The script waits up to 10 minutes, checking every 30 seconds.

• If CI passes, proceed to merge
• If CI fails, stop and report the failure to the user. Do NOT merge.

7. Squash Merge

gh pr merge --squash --delete-branch

8. Clean Up

git checkout main
git pull origin main

Report success to the user with the merged PR URL.

Creating a Release

When the user asks to create a new release (e.g., "new release", "cut a release"):

• Update the VERSION file with the new version number
• Update all version references in the "Pre-built binaries" section of README.md: the archive filenames and download URLs in the platform table, and the curl install example
• Then follow the normal commit workflow above with message chore: bump version to <version>