ワンクリックで
gh-close-plan
Close a GitHub plan issue with a summary. Use when the user tells you to "close the github plan issue".
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
メニュー
Close a GitHub plan issue with a summary. Use when the user tells you to "close the github plan issue".
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Create a GitHub PR from the current branch. Use when the user asks to "create a PR", "open a pull request", or "submit a PR".
Update a GitHub plan issue with progress. Use when planning a task, or when the user tells you to "update the github plan issue".
Create a plan issue on GitHub. Use when planning a task, or when the user tells you to "create a github plan issue" with the repo name as argument.
Prepare a handover for continuing work in a new session. Use when the user asks to "hand over", "prepare handover", "wrap up for a new session", or "context dump".
Implement a GitHub plan issue step by step with checkpoints. Use when the user asks to "implement the plan", "start working on the plan", or "execute the plan".
Read the GitHub plan issue given as argument. Use when the user tells you to "read this github plan issue" with the issue as argument.
| name | gh-close-plan |
| description | Close a GitHub plan issue with a summary. Use when the user tells you to "close the github plan issue". |
| argument-hint | [owner/repo#number] |
| allowed-tools | Bash, Read, Write, Edit |
Never @mention other users in plan issues or comments.
Close the GitHub issue $ARGUMENTS (issue URL or owner/repo#number). If no argument is given, use the issue referenced earlier in this conversation. If no issue can be determined, ask the user.
Workflow for editing issue bodies and comments:
mktemp -d /tmp/plan-close-XXXXXgh api and capture the output. Use the Write tool to save it to files in the temp directory (e.g. body.md, comment-COMMENTID.md). Do NOT use shell redirects (>) to write files, as this triggers permission prompts.--input with jq to properly JSON-encode the content:jq -Rs '{body: .}' <tempdir>/body.md | gh api repos/OWNER/REPO/issues/NUMBER -X PATCH --input -jq -Rs '{body: .}' <tempdir>/comment.md | gh api repos/OWNER/REPO/issues/NUMBER/comments --input -jq -Rs '{body: .}' <tempdir>/comment-COMMENTID.md | gh api repos/OWNER/REPO/issues/comments/COMMENT_ID -X PATCH --input -Never embed content directly in shell arguments or use -f body=@file (it uploads the literal string, not the file contents). Always fetch the latest from GitHub before making changes. Do not rely on previously fetched copies that may be stale.
Read the issue and its comments to understand the full history of the work.
Check off completed steps (- [x]) based on the work done. Steps may be in a separate Steps comment (new format) or in the issue body (old format). Check both locations.
Verify that all steps are checked off. If any are incomplete, ask the user whether to proceed or leave the issue open.
Add or update a Commits table comment with the final commit hashes from main. Feature branch hashes change after squash/rebase merge, so look up the corresponding commits on main and replace the old hashes.
Clean up session comments: Delete all individual session comments and replace them with a single consolidated Session Log comment. Structure it with dated sections (### YYYY-MM-DD) for each session that contributed something worth keeping. Include only key findings, decisions, and insights. Drop sessions that had nothing noteworthy. Remove back-and-forth, minor details, and redundant information.
Capture learnings: Before closing, review the session for non-obvious discoveries worth persisting. Ask the user: "Anything worth capturing?" If yes, propose where each belongs:
docs/ or similar): architecture insights, design rationale useful to humans tooApply confirmed items. If the user says nothing to capture, move on.
Add a closing comment summarizing:
Close the issue.