Problem
idd-implement's PR body template at Step 5.5 contains a self-defeating warning that itself triggers GitHub's auto-close parser. Concrete repro: che-apple-mail-mcp#99 auto-closed when PR #121 merged, before /idd-close could enforce the checklist gate + closing-summary discipline.
Reproduction
idd-implement Step 5.5 generates a PR body footer like:
---
Generated by /idd-implement on PR path. **Do NOT add 'Closes #${NUMBER}'** — IDD discipline requires manual /idd-close after merge to enforce checklist gate + closing summary.
For ${NUMBER}=99, this expands to literal text containing the substring Closes #99. GitHub's keyword parser ignores quoting and code-formatting context — it just sees Closes #99 in the PR body and registers it as a closing reference. When the PR squash-merges to the default branch, GitHub fires the auto-close event on issue #99.
Observed:
$ gh pr view 121 --json closingIssuesReferences
{"closingIssuesReferences":[{"number":99,"repository":{"name":"che-apple-mail-mcp",...}}]}
(closingIssuesReferences populated despite the warning's intent.)
Type
bug (template self-defeat)
Severity
P2 — bypasses the IDD idd-close gate completely. Every PR generated by idd-implement containing this footer has the same flaw. Affected: all post-Step-5.5 PRs (the warning was added precisely to remind users not to add Closes #N — ironic).
Expected
The PR footer should reference the trigger phrase without GitHub auto-parsing it. Options:
- Break the phrase:
"Do NOT add a close trailer ('Clos' + 'es #${NUMBER}' or similar)" — clunky but parse-safe
- Use a comment / footnote:
**Do NOT add close trailers** (\Closes/Fixes/Resolves #N` will skip the /idd-close gate)`
- Reference the issue obliquely:
**Do NOT add close trailers to this PR — IDD discipline requires manual /idd-close after merge** (drop the #${NUMBER} from the warning entirely; the PR title already has it)
Option 3 is cleanest — the warning doesn't need to repeat the issue number to be effective. The Refs #${NUMBER} at the top of the PR body already establishes the link without triggering close.
Actual
Current Step 5.5 template literally includes 'Closes #${NUMBER}' inside quotes, expecting GitHub to ignore quoted-context as if it were code. It doesn't.
Recommended fix
skills/idd-implement/SKILL.md Step 5.5 PR_BODY template — change:
-Generated by /idd-implement on PR path. **Do NOT add 'Closes #${NUMBER}'** — IDD discipline requires manual /idd-close after merge to enforce checklist gate + closing summary.
+Generated by /idd-implement on PR path. **Do NOT add a GitHub close trailer to this PR** — IDD discipline requires manual /idd-close after merge to enforce checklist gate + closing summary.(No #${NUMBER} in the warning at all.)
Reproduction context
Severity classification
Could be argued P1 (bypasses core IDD discipline) but P2 fits because:
- Retroactive recovery exists (post Closing Summary, skip reopen→reclose)
- The skill itself documents the recovery path
- Issue body still has all the lifecycle artifacts (diagnosis / plan / impl / verify); only the "post-merge Closing Summary before issue close" sequence is broken
But it's a P2 in the "every PR carries the bug" sense — high-frequency, low-blast-radius.
Audit trail
This issue itself was surfaced during /idd-close che-apple-mail-mcp#99 (the very close it was meant to enable).
Problem
idd-implement's PR body template at Step 5.5 contains a self-defeating warning that itself triggers GitHub's auto-close parser. Concrete repro:che-apple-mail-mcp#99auto-closed when PR #121 merged, before/idd-closecould enforce the checklist gate + closing-summary discipline.Reproduction
idd-implementStep 5.5 generates a PR body footer like:For
${NUMBER}=99, this expands to literal text containing the substringCloses #99. GitHub's keyword parser ignores quoting and code-formatting context — it just seesCloses #99in the PR body and registers it as a closing reference. When the PR squash-merges to the default branch, GitHub fires the auto-close event on issue #99.Observed:
(
closingIssuesReferencespopulated despite the warning's intent.)Type
bug (template self-defeat)
Severity
P2 — bypasses the IDD
idd-closegate completely. Every PR generated byidd-implementcontaining this footer has the same flaw. Affected: all post-Step-5.5 PRs (the warning was added precisely to remind users not to addCloses #N— ironic).Expected
The PR footer should reference the trigger phrase without GitHub auto-parsing it. Options:
"Do NOT add a close trailer ('Clos' + 'es #${NUMBER}' or similar)"— clunky but parse-safe**Do NOT add close trailers** (\Closes/Fixes/Resolves #N` will skip the /idd-close gate)`**Do NOT add close trailers to this PR — IDD discipline requires manual /idd-close after merge**(drop the#${NUMBER}from the warning entirely; the PR title already has it)Option 3 is cleanest — the warning doesn't need to repeat the issue number to be effective. The
Refs #${NUMBER}at the top of the PR body already establishes the link without triggering close.Actual
Current Step 5.5 template literally includes
'Closes #${NUMBER}'inside quotes, expecting GitHub to ignore quoted-context as if it were code. It doesn't.Recommended fix
skills/idd-implement/SKILL.mdStep 5.5 PR_BODY template — change:(No
#${NUMBER}in the warning at all.)Reproduction context
~/.claude/plugins/cache/issue-driven-development/issue-driven-dev/2.59.0/skills/idd-implement/SKILL.md)/idd-closeskill's "trailer recovery" instructionSeverity classification
Could be argued P1 (bypasses core IDD discipline) but P2 fits because:
But it's a P2 in the "every PR carries the bug" sense — high-frequency, low-blast-radius.
Audit trail
This issue itself was surfaced during
/idd-close che-apple-mail-mcp#99(the very close it was meant to enable).