From 80282ff8884a873dc69f27ac71fd5dd27d74dfc3 Mon Sep 17 00:00:00 2001 From: amcheste-ai-agent <278991699+amcheste-ai-agent@users.noreply.github.com> Date: Mon, 11 May 2026 21:42:07 -0400 Subject: [PATCH] feat(skill): publish-release flips GitHub default to main on first release MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Implements Step 5 of the release ceremony documented in engineering-handbook PR #19. The integration trunk stays on develop; this only touches GitHub's separate "default branch" repo setting, which controls the landing page, clone target, and PR-base UI default. After the tag pushes and the pipeline starts, check the current default. If it's still develop (first release), flip to main. If it's already main (subsequent release), no-op. The check is idempotent so the skill can run it unconditionally without risk. Contributors keep branching from and PRing to develop — only the repo's public-facing default changes. Co-Authored-By: Claude Opus 4.7 (1M context) Co-Authored-By: amcheste <13696614+amcheste@users.noreply.github.com> --- claude-skills/publish-release/SKILL.md | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/claude-skills/publish-release/SKILL.md b/claude-skills/publish-release/SKILL.md index 354a1ee..cd0a275 100644 --- a/claude-skills/publish-release/SKILL.md +++ b/claude-skills/publish-release/SKILL.md @@ -92,6 +92,27 @@ Show the user the release pipeline URL and confirm the tag was pushed. Let them - If the version contains `-` (e.g. `-beta.1`, `-rc.1`) it is published as a **pre-release** and will not show as the latest version - If it is a stable version (e.g. `1.0.0`) it becomes the **latest** release after all pipeline gates pass +## Step 5 — Ensure `main` is the GitHub default branch + +`develop` is the integration trunk and stays the same. GitHub's "default branch" repo setting is separate — it controls landing page, `git clone` target, and PR-base UI default. The convention (see [Branching & Releases](https://github.com/amcheste/engineering-handbook/blob/develop/docs/workflows/branching-and-releases.md#github-default-branch-setting)) is: + +- Pre-release: GitHub default = `develop` (the only meaningful state) +- Post-release: GitHub default = `main` (external visitors see the shipped product) + +Run this unconditionally at the end of the release flow. It's idempotent: on the first release it flips develop → main, on every subsequent release it's a no-op. + +```bash +current=$(gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name') +if [ "$current" != "main" ]; then + gh repo edit --default-branch main + echo "GitHub default branch flipped to main (first release)." +else + echo "GitHub default branch already main." +fi +``` + +Contributors keep branching from and PR'ing to `develop` — only what GitHub renders on the repo landing page changes. + ## Summary Tell the user: @@ -99,3 +120,4 @@ Tell the user: - That the pipeline is running: validate → VM acceptance → publish - Where to watch it: `https://github.com/amcheste//actions` - That `main` now equals the new release and `develop` is ready for the next cycle +- If Step 5 flipped the default branch, mention it explicitly (it's the first release)