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

### 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 #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 #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 #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 #4.

7. PR #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