prep-pr-close-keyword-auto-closes-issuelisted

Diagnose and prevent the trap where a scaffolding/prep/planning/handoff PR (one that ships a paste-ready prompt, an ADR, an implementation plan, or any docs-only artefact describing FUTURE work) contains a close-keyword like `closes #N` / `fixes #N` / `resolves #N` in its TITLE or BODY, which GitHub auto-applies at merge time — closing issue #N BEFORE the actual implementation work has been done. Use when: (1) `gh issue view <N>` reports the issue CLOSED but you know the work hasn't run, (2) you're about to open a PR shipping a "next-session prompt" / "implementation plan" / "ADR proposal" / "scaffolding" and the title or body references an issue, (3) `gh api repos/<O>/<R>/issues/<N>/timeline` shows the closing commit is a docs-only PR (only `docs/handoffs/`, `docs/plans/`, `docs/decisions/`, or `docs/specs/` paths changed), (4) a fresh session is asked to execute an issue that already shows as CLOSED. Different from `gh-squash-merge-closes-only-one-issue` (THERE: one of many issues closed on merge; HERE: an
wan-huiyan/agent-traffic-control · ★ 1 · Data & Documents · score 80

Install: claude install-skill wan-huiyan/agent-traffic-control

# Prep PR close-keyword auto-closes issue prematurely ## Problem You wrote a docs-only PR shipping a paste-ready prompt / implementation plan / ADR proposal / scaffolding for future work on issue #N. The PR title looked like: > `docs(s171): next-session prompt — backfill historical sf_enrolled (closes #672)` or the PR body opened with: > Paste-ready S171 prompt for the historical `sf_enrolled` backfill that > pre-empts Q3 2026 calibration retrain. Closes-ready for issue #672 (P1). The PR squash-merged cleanly. Hours or days later, someone (you or the next session) starts executing the prompt. They run `gh issue view 672` and find: ```json {"closed":true,"closedAt":"2026-05-11T11:27:12Z","stateReason":"COMPLETED"} ``` But the work hasn't run yet. The issue closed because GitHub's keyword parser treated `closes #672` in the prompt PR's title/body as a close-keyword and fired at merge time — even though the merged diff was a docs-only handoff file, not the implementation. This silently misrepresents repo state. Stakeholders asking "what's left?" get a falsely-clean issue list. Future audits ("we shipped #672 — where's the postmortem?") chase ghosts. ## Context / Trigger Conditions Use this skill when ANY of these hold: 1. **Discovery (after the fact)**: `gh issue view <N> --json state,closedAt,stateReason` shows CLOSED, but you have direct evidence (a worktree branch, a prompt doc, a session handoff) that the implementation hasn't run. 2. **Pre-flight check at