Release PR fails to inherit Closes #N keywords from constituent PRs (Submitted from external project)

[sebastientaggart]

Summary

When /deploy creates the release PR (dev → main), it does not reliably propagate the Closes #N keywords from the constituent PRs into the release PR's own body. Issues
that were Closes-marked in a dev-target PR stay open after the release ships, because GitHub's closing-keyword parser scans only the merging PR's body — not the bodies
of intermediate dev-target PRs. This is compounded by another problem: PR-authoring agents sometimes write Issue #N (a plain link) when they mean Closes #N, and /deploy
has no way to recover the intent at release time.

Repro

1. Branch off dev → write a fix → open PR with body containing Closes Add shields.io badges and MIT LICENSE file #123 → merge to dev. GitHub does not auto-close Add shields.io badges and MIT LICENSE file #123 (it auto-closes only on default-branch
   merges). This is expected GitHub behavior, not the bug — context for the next step.
2. Repeat for several issues over weeks.
3. Run /deploy. The release PR is created targeting main with a Closes #N block.
4. After the release PR merges, observe that some issues whose constituent PRs did say Closes #N are still open.

Root cause (two compounding)

1. /deploy Step 2 extracts both Closes #N and Issue #N from constituent PR bodies but appears to merge them into a single linked-issues set used for display, then writes
   the release PR body without distinguishing which were close-intent vs. reference-intent. The release PR's auto-close set is incomplete as a result.
2. PR-authoring (/start and /submit-for-review) doesn't enforce which closing form to use. Issue #N is just a link — it does not trigger auto-close at any merge target.
   So even if /deploy fixed the propagation, the constituent PRs with Issue #N bodies still wouldn't auto-close. There's no semantic distinction in the data being read.

What good looks like

• /start and /submit-for-review should require Closes #N (not Issue #N, not Fixes #N-style alternates) when a PR fully resolves a ticket, and instruct the author to
  write Related to #N (not auto-closing) for context-only references. The distinction is editorial but the skill can enforce it.
• /deploy Step 2 should parse Closes #N separately from Issue #N / Related to #N, and the release PR body should reproduce the exact Closes #N lines from every
  constituent PR — verbatim. Anything that's Closes-tagged in a constituent must appear Closes-tagged in the release PR. Step 5's HUMAN GATE should display this
  explicitly: "Issues that will close on merge: #A, #B, #C" vs "Issues referenced but not closing: #X, #Y" so the operator can spot a missing close at gate time.

Concrete evidence from this deploy (v0.12.0)

Four issues had their fixing PR shipped in v0.12.0 but were not auto-closed by the release PR (#326) because the release PR body did not include Closes #N for them:

┌───────┬────────────────┬───────────────────────────────────────────────────────────────────────────────────────────────┐
│ Issue │ Constituent PR │ What its body said │
├───────┼────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────┤
│ #319 │ #321 │ Issue #319 (link only — no close intent recoverable) │
├───────┼────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────┤
│ #317 │ #320 │ Issue #317 (same) │
├───────┼────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────┤
│ #269 │ #272 │ Issue #269 (same) │
├───────┼────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────┤
│ #271 │ #286 │ Closes #271 (close intent was present in constituent body but dropped at release-PR assembly) │
└───────┴────────────────┴───────────────────────────────────────────────────────────────────────────────────────────────┘

Three more (#223, #232, #253) shipped in earlier releases without ever being closed — the same bug, accumulated over time. After v0.12.0 merged, the operator audited and
closed all seven manually.

Severity

Medium. No data loss, but the backlog drifts further from reality every release. Operators discovering it after the fact (as here) is expensive: each missed issue
requires verifying which PR closed it, which release shipped it, then writing a close comment.

Workaround until fixed

In the /deploy Step 5 HUMAN GATE, the operator should ask: "Show me every PR's Closes #N lines as a single list, and confirm they all appear in the release PR body's
Closes block." This is what the skill should be doing automatically.

[sebastientaggart]

Investigation Findings

Confirmed both root causes in the skill sources and settled on the fix shape:

• The data loss starts at PR-authoring, not at /deploy. submit-for-review currently tells dev-target PRs to write Issue #N (a plain link). That form carries no recoverable close-intent, so weeks later /deploy genuinely cannot tell "this should close" from "this is just referenced." The fix switches the convention to a recoverable semantic distinction: Closes #N = fully resolves the ticket, Related to #N = context-only.

• Closes #N is safe on a dev-target PR. GitHub only acts on closing keywords when a PR merges into the default branch (main). On a dev merge the keyword is inert — it records intent without prematurely closing. /deploy then harvests those exact lines into the release PR (which does target main) and the auto-close fires there.

• /deploy will parse two separate sets. A close-set (Closes #N, reproduced verbatim into the release PR body) and a reference-set (Related to #N). The Step 5 HUMAN GATE will show them as distinct lists — "Issues that will close on merge" vs "Referenced but NOT closing" — so a missing close is visible at gate time.

• /start needs no change. The ticket attributes part of the problem to /start, but start.md has no closing-keyword handling at all — it only creates the issue and branch. All PR-body enforcement lives in /submit-for-review.

• Legacy Issue #N PRs already merged to dev: no migration machinery. /deploy buckets Issue #N into the reference-set so any straggler stays visible at the gate; the operator closes it manually if needed. These skills run only on a handful of small private projects, so manual cleanup of in-flight stragglers is acceptable and a transition window would be over-engineering.

[sebastientaggart]

Resolution

The release process now reliably carries "this fixes issue N" markers all the way through to the production release, so issues close automatically when their fix ships instead of silently staying open. When a fix is submitted, it's now tagged with clear close-intent that the release step reproduces exactly, and the release confirmation screen shows two separate lists — issues that will close versus issues only referenced — so a missing one is caught before shipping. Older items that were only loosely linked still show up on that confirmation list so they can be closed by hand if needed.

See #188 for full technical details.