close-issue
SolidClose a GitHub or GitLab issue with a summary comment
Install
Quality Score: 87/100
Skill Content
Details
- Author
- desplega-ai
- Repository
- desplega-ai/agent-swarm
- Created
- 5 months ago
- Last Updated
- today
- Language
- TypeScript
- License
- MIT
Integrates with
Similar Skills
Semantically similar based on skill content — not just same category
closing-issues
Close a GitHub issue with a synthesis comment as a flowing graph — validate the synthesis, post the closing comment, close, then run a pluggable callback (e.g. memory store) detached. Use when closing an issue should also capture the LEARNING (not just the diff log) and when the post-close work shouldn't block the close ack.
implement-issue
Implement a GitHub issue or GitLab issue and create a PR/MR
gh-squash-merge-closes-only-one-issue
GitHub auto-close on squash-merge only catches ONE issue per PR even when the PR title/body says "Closes #447, #448, #449, #450". The first issue closes; the rest stay OPEN. Use when: (1) you opened a PR with a title or body listing multiple "Closes #X, #Y, #Z" references, (2) the PR squash-merged successfully (`gh pr view N --json state` = MERGED), (3) `gh issue list --state open` shows some of the referenced issues are still OPEN. Root cause: GitHub's auto-close keyword parser binds one keyword to one issue; "Closes #447, #448" is interpreted as "Closes #447" plus an inline reference to #448. Fix: either (a) write one keyword per issue ("Closes #447. Closes #448. Closes #449.") in the PR body BEFORE merging, or (b) post-merge, run `gh issue close $N --comment "Closed by PR #M (squash-merge auto-close caught only one)"` for each leftover. Different from `pr-followup-commit-stranded-after-squash` (which covers stranded COMMITS, not stranded ISSUES). Saves a "why are my issues still open after merging the fix?
respond-github
Respond to a GitHub issue/PR or GitLab issue/MR
prep-pr-close-keyword-auto-closes-issue
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