get a github issue list with the filters you mean
walk into the handover knowing which issues still need an owner. give the bot a github repository and narrow it by label, assignee, milestone or recent updates.
it brings the matching work here without editing the queue. github includes pull requests too, so ask for those in a separate list.

where it helps
- find unassigned accessibility reports before deciding who can help
- list a teammate’s issues before a coverage handover
- collect a milestone’s work without moving or reprioritising it
- find closed issues that picked up fresh activity this week
the short version
get the queue down to the work you can act on. name the assignee, label, milestone or state you need. the bot can find a milestone's number from its name.
'updated since monday' includes older issues with new activity. use opening dates when you want new issues. long lists arrive in batches of up to 100; have the bot reach the end before counting.
step by step
- connect github with read only for a report that changes nothing
- paste the repo link and name the label, person or milestone
- read the filters beside the first result and find the separate pull request list
- schedule the report, then pause it when the staffing question ends
send this to your bot
paste this into a chat with your bot
every wednesday at 11, list open, unassigned issues labelled accessibility in hazelpoint/atlas-desk. finish every result batch. keep pull requests separate. show issue numbers, titles and the filters you used here. report any batch you could not read. if no issues match, say so. never assign people, add labels or close anything.- when
- wednesdays at 11:00
- needs
- github connected; read only repository access
what comes back looks like this (an example)
hazelpoint/atlas-desk
filters: open, unassigned, accessibility
#118 keyboard focus missing on search
#126 chart labels need text alternatives
pull requests excluded from the issue count.what can go wrong
- pull requests can inflate the count. ask for separate lists.
- old work can come back to life. use updated for recent activity, opened for newly filed issues.
- repo names can repeat. paste the full github link.
permissions and asking first
dusk bot counts List repository issues as a read: it looks and changes nothing. a bot you allow only to read can use it.
the permissions GitHub asks for to run it: repo.
inputs
| input | required | what it is |
|---|---|---|
repo | yes | REQUIRED. |
owner | yes | REQUIRED. |
page | no | Page number for the set of results. |
sort | no | The field to sort the results by. |
type | no | Filter issues by type name. |
since | no | Filters issues to include only those updated at or after the specified time. |
from composio's catalog for GitHub (action GITHUB_LIST_REPOSITORY_ISSUES, read 12 november 20264). your bot fills these in from what you tell it.
try it in 2 minutes
- connect github with read only
- paste one repository link
- ask for open issues with one exact label
- read the filters beside the issue count
mistakes people make
counting pull requests as unresolved reports
ask for issues and pull requests in separate groups.
asking for new issues with an update filter
say whether you mean opening dates or recent activity.
questions
can it show only issues nobody owns?
yes, unassigned is a supported filter. add a label or milestone to keep the list short.
why are old issues appearing in my weekly list?
someone touched them this week. the update filter includes old issues with new activity during your chosen week.
sources
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].
triage a github issue when it opens
a github bot that reads the work before you weigh in
ask ai to add the right labels to a github issue
close a specific github issue after you confirm the outcome
write the github issue comment that moves things along
read one github pull request before the next decision