Train GH Copilot to understand how branches, merges and PRs work

[keithboone]

Describe the bug

GH Copilot and I were doing some very simple work on a library (IZGateway/uuid-cjs). I was testing push/PR/merge/release process for this. The merge failed, and GH Copilot didn't understand enough about how GH works to understand that it could just open a new PR, on the existing branch. It further didn't realized that a merged branch closes the PR. It also did not understand how to create a new PR with a whitespace fix to trigger a new CICD run. For something named GitHub Copilot, it is remarkably dense about typical GitHub workflow patterns.

Affected version

GitHub Copilot CLI 1.0.39

Steps to reproduce the behavior

Context

Working in IZGateway/uuid-cjs to get a new npm package published to GitHub Packages via a CI/CD pipeline. The workflow has
two jobs: dev-publish (on PR open/sync) and release (on PR merge).

---

Steps Taken

1. PR Create ownership.yaml #1 merged → release fired, tag step failed

• Release job ran correctly: bumped to 14.0.1, published to GitHub Packages.
• Failed: git tag "v14.0.1" — tag already existed (created earlier by npm version).
• Root cause: npm version without --no-git-tag-version silently creates a local git tag before the explicit git tag step.

2. PR Update ownership.yaml #2 created with fixes

• Added .npmignore (package was publishing 34 files including .github/ and openspec/; reduced to 4).
• Fixed repository.url to use git+ prefix.
• Fixed dev publish version logic (was using npm version double-call; replaced with direct node -e JSON write).
• Changed release job to use --no-git-tag-version + git tag -f + --force push.

3. PR Update ownership.yaml #2 merged → release job fired spuriously, published 14.0.2, tag step failed again

• The -f fix was in the PR but the run used the pre-merge workflow.
• 14.0.2 was published successfully but tags v14.0.2 and v14 were never created.

4. Tags manually created

• Copilot ran: git tag -f v14.0.2 , git tag -f v14 , pushed both with --force.
• Tags v14.0.2 and v14 now exist on the remote.

5. Needed to verify the fixed workflow on main

• Copilot incorrectly assumed that since both branches were merged, a new branch was required.
• User corrected: merged branches persist on the remote and can be used to open new PRs.
• Copilot created a PR from fix/package-and-ci-cleanup against main — but the branch had no diff, so the PR was
  empty/meaningless.
• User said "No." Copilot closed the empty PR.

6. User clarified intent

"I want you to create a new PR from the existing branch, doing a whitespace fix if that's what you need for there to be a
diff so that the PR can be opened."

• Copilot added a trailing newline to README.md, committed as chore: trailing newline in README, pushed to
  fix/package-and-ci-cleanup, and opened PR Updating exec sponsor per request from the TPM org #4.

7. PR Updating exec sponsor per request from the TPM org #4 CI ran and passed

• Two runs fired (one per push event on open).
• Both completed with ✓ status.
• Fixed workflow is confirmed working on main.

---

Issues Encountered with Copilot

┌───┬──────────────────────────────────────────────────────────────────────┬──────────────────────────────────────────────┐
│ # │ Issue │ Impact │
├───┼──────────────────────────────────────────────────────────────────────┼──────────────────────────────────────────────┤
│ 1 │ Assumed merged branches could not be re-used for new PRs │ Required user correction; created and closed │
│ │ │ a useless empty PR │
├───┼──────────────────────────────────────────────────────────────────────┼──────────────────────────────────────────────┤
│ 2 │ Did not proactively suggest a whitespace-fix approach when the │ Required explicit instruction from user │
│ │ branch had no diff │ │
├───┼──────────────────────────────────────────────────────────────────────┼──────────────────────────────────────────────┤
│ 3 │ Multiple "Stop" messages needed before Copilot ceased polling for a │ Frustrating UX; required 4+ stop │
│ │ new CI run after PR #2 merge │ instructions │
└───┴──────────────────────────────────────────────────────────────────────┴──────────────────────────────────────────────┘

Expected behavior

This is what GH thinks about what the behavior should have been:

For step 5, when I discovered the branch had no diff, I should have immediately proposed adding a trivial commit to create one — not created an empty PR, not asked about it, just said "the branch has no diff; I'll add a whitespace fix and push" and done it.

The user's correction ("merged branches don't go away") was a hint, not a complete instruction. I should have understood the intent from that hint rather than needing it spelled out explicitly a second time.

Additional context

Windows 10