← ClaudeAtlas

closing-issueslisted

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.
oaustegard/claude-skills · ★ 124 · Code & Development · score 84
Install: claude install-skill oaustegard/claude-skills
# Closing Issues A `flowing` graph that turns "close GitHub issue + capture what I learned" into a structural DAG. The synthesis text is validated upfront, the close happens against the GitHub API, and an optional post-close callback runs detached so the close ack is unblocked. ```python from closing_issues import close_issue result = close_issue( repo="owner/repo", number=42, synthesis=( "Pattern X works because of Y. Constraint: don't apply to Z. " "Future note: revisit when feature Q lands." ), ) print(result["issue_url"]) # https://github.com/.../issues/42 print(result["comment_url"]) # ...#issuecomment-... ``` ## Why a synthesis, not a "done" comment Closing an issue produces two artifacts: - **The Issue itself** — implementation log. The diff and commit history already show *what* was done. - **The closing comment / synthesis** — what was *learned*. Lasts longer than the diff in mental cache. Good closing comments lead with *why*, not *what*. Failure modes, constraints discovered, alternatives rejected. The synthesis is the seed of an institutional memory. ## Internal shape ``` prepare_synthesis ──▶ close_github_issue [terminal] │ └──▶ post_close_callback [detached, when=callback] ``` - **`validate=must_have_synthesis_text`** runs against the raw input string. Empty or whitespace-only → FAILED with no GitHub API call. This is structural: callers