close a specific github issue after you confirm the outcome

get finished work out of the open queue, with the right reason attached. the bot can close a github issue as completed or not planned.

by the dusk bot team · checked 12 november 2026 · how we made this

paste its full link so it finds the right repository. want the final say? tell it to show the title and closure reason, then wait for your answer. closures do not pause automatically.

pixel art: a lime pixel bot and a sky blue pixel bot beside the GitHub mark on a white tile, a folder of papers and a big button, on a lilac hill in front of snowy hills and green fields, one saying "confirm then close"

what it does

leave the next reader a clear decision. completed means the work passed its acceptance criteria. not planned means you decided against doing it. closing takes the issue out of the open queue.

it changes the state and optional reason. code still needs its own fix and merge; an explanation needs a separate comment.

have the bot read the owner’s latest reply before proposing closure. an old report can still describe a live problem.

when you would use it

finish verified work. close an issue after its acceptance test passes.
make the product decision clear. mark a rejected feature request not planned.
clear an obsolete task. get its owner’s agreement before closing it.

try it

paste this into a chat with your bot

every second friday at 11, read open issues in fieldnote-co/visitor-map and their latest comments. find ones where the owner says the acceptance test passed. show each title, issue number and supporting comment here. propose closing those as completed. ask me before you change anything. close only the issues i choose and report their resulting states. do not treat age or silence as proof.

when: alternate fridays at 11:00
needs: github with read and write; access to read and close issues in fieldnote-co/visitor-map

what comes back looks like this (an example)

closure proposal

fieldnote-co/visitor-map #41: keep the accessible entrance route
the owner reports a passed acceptance test in the issue discussion.
proposed reason: completed

close #41 as completed? the owner’s comment is beside the proposal.

set it up

name the repository. connect github and paste the full issue link, including its number.
read the owner’s reply. start read only and compare the bot’s proposal with the issue discussion.
keep the last word. allow read and write, then say “ask me before you close anything”.
open the issue afterwards. its state and reason should match your decision. pause the routine when the project ends.

what it needs from you

input	required	what it is
`repo`	yes	The name of the repository without the `.git` extension.
`owner`	yes	The account owner of the repository.
`issue_number`	yes	The number that identifies the issue.
`state_reason`	no	Reason for closing an issue.

from composio's catalog for GitHub (action GITHUB_CLOSE_ISSUE, read 12 november 2026⁴). your bot fills these in from what you tell it.

how dusk bot handles it

dusk bot counts Close an issue as a change: it alters something in GitHub, and the sending setting does not cover it. a bot you allow only to read can never call it.

the permissions GitHub asks for to run it: repo, public_repo.

where it stops

numbers repeat across repositories. #41 alone can point to the wrong report. include the owner and repository.
not planned tells the truth about rejected work. completed tells readers the work was done.
comments are a separate step. closing alone leaves no written explanation for the decision.

try it in 2 minutes

paste an issue link
ask for its title and current state
ask which closure reason fits the evidence
review the proposal before allowing a change

quick checklist

the title and repository match
the acceptance test or product decision supports closure
the reason says what actually happened
the bot must ask before changing the state

mistakes people make

closing the oldest reports first

age proves nothing. require an owner decision or a passed acceptance test.

calling rejected work completed

choose not planned so the next person understands what happened.

questions

will closing the issue post an explanation?

no. it changes the state and can add a closure reason. a written explanation needs a separate comment action.

can it close an issue that will never be implemented?

yes, with not planned as the reason. ask to see that reason before the change. completed would give people the wrong impression.

sources

dusk bot docs: files and apps
dusk bot docs: routines
dusk bot docs: a bot's computer
composio, GitHub toolkit (catalog version 20261104_00), checked 12 november 2026

drafted with ai help from the dusk bot docs and the sources listed on this page, then checked against them. if something here is wrong or out of date, write to [email protected].