The gap
The template teaches instances to write Closes #N in a PR body so GitHub auto-closes resolved issues, and separately encourages PR bodies that explain what was not done. Those two habits collide: GitHub's closing-keyword parser does not understand negation. A body line such as
Does not close #42 — that needs a follow-up cycle.
or
This does not fix #17; the root cause is upstream.
still registers close #42 / fix #17 and closes the issue on merge. The loop then reports the issue as resolved when its own PR body says it is not.
Reported independently by: fiefs-dev-loop#19, graphik-dev-loop#5, professions-dev-loop#9.
Why it matters
This fails in the direction that loses work. A wrongly-closed issue drops out of the next cycle's triage, so the gap it recorded is silently abandoned — and because the PR body reads as if the exclusion was handled deliberately, nothing in a later self-audit flags it.
Suggested resolution
Add a Phase 4 rule, and a matching self-review rubric row:
Never write a closing keyword (close/closes/closed, fix/fixes/fixed, resolve/resolves/resolved) followed by an issue reference unless that PR genuinely closes it — negation does not suppress the keyword. To refer to an issue without closing it, write the bare reference (#42) or a non-keyword phrase such as "tracked separately in #42" or "out of scope for this PR: #42".
The Phase 4 "verify each Closes #N" step should be extended to run in the other direction as well: scan the body for every closing keyword and confirm each one is intended, not merely that each intended close is present.
drafted by Claude on behalf of Daniel Stephenson
The gap
The template teaches instances to write
Closes #Nin a PR body so GitHub auto-closes resolved issues, and separately encourages PR bodies that explain what was not done. Those two habits collide: GitHub's closing-keyword parser does not understand negation. A body line such asor
still registers
close #42/fix #17and closes the issue on merge. The loop then reports the issue as resolved when its own PR body says it is not.Reported independently by:
fiefs-dev-loop#19,graphik-dev-loop#5,professions-dev-loop#9.Why it matters
This fails in the direction that loses work. A wrongly-closed issue drops out of the next cycle's triage, so the gap it recorded is silently abandoned — and because the PR body reads as if the exclusion was handled deliberately, nothing in a later self-audit flags it.
Suggested resolution
Add a Phase 4 rule, and a matching self-review rubric row:
The Phase 4 "verify each
Closes #N" step should be extended to run in the other direction as well: scan the body for every closing keyword and confirm each one is intended, not merely that each intended close is present.drafted by Claude on behalf of Daniel Stephenson