a github bot that reads the work before you weigh in

what a bot can do in GitHub

github work often starts with a question: is this report new, what changed, or who is waiting? these actions let a bot collect the evidence before suggesting a next step.

composio, the connection service dusk bot uses for apps, lists 905 GitHub actions (catalog version 20261104_00, read 12 november 2026⁵). dusk bot treats 474 of them as reads, 13 as sends and the other 418 as changes. an action counts as a read only when its name starts with a read word like get, list or search, so a bot you allow only to read can never call the rest. a send is anything that reaches a person outside the app or moves money, like add email for auth user: it waits for your Allow unless you've given that bot a daily amount it may send alone.

connect GitHub

1. open Connected apps in the sidebar.
2. pick GitHub and sign in on GitHub's own page, so your password goes to them and never to a bot.
3. choose which bots may use it, and whether each may only read or may also change things. your bookkeeper doesn't need your GitHub.
4. ask in plain words. reading and drafting happen freely; sending asks you first.

open Connected apps, connect github and give access to the bot doing repository work. sign-in takes place on github's page. tell the bot the exact owner and repository, then choose read-only access for its first review. an action being in the catalog does not mean you have allowed that bot to use it.

routines to copy

try these as messages to a repository bot. each keeps the decision in your chat, so you can check the evidence before adding writes.

when a github issue opens in acme/widget, read it and search existing issues for the same error. tell me possible duplicates and which reproduction details are missing. do not label, assign, close or comment.

every tuesday at 10, read open pull requests in acme/widget and their reviews. group them into waiting for author, waiting for reviewer and unclear. cite the review that supports each choice. leave everything unchanged.

every thursday at 3, list commits in acme/widget since monday. draft a release outline in this chat, grouping fixes and additions. mark anything whose user impact is unclear. do not create a release or tag.

what it asks you first

posting an issue comment is a send: by default it brings up Allow or Deny. a daily sending amount can change that, and so can Full access for a bot with no sending rule of its own (up to 25 a day), so check the bot's sending setting before enabling comments.

labels, assignments, issue closure, merges and submitting a pull request review are other kinds of changes. do not assume they pause for a send card. keep the bot read-only for review work, or include "ask me before you change anything" in a routine that needs write access.

what it cannot do

• merge, label or assign with a read-only github grant. the permission check stops a write before it reaches the app; reading a pull request is not permission to merge it.
• keep triaging on a sleeping laptop. local event routines need dusk bot running and the computer awake. use dusk cloud if the repository needs attention while your machine is off.
• prove a fix works just by reading an issue or diff. these routines collect repository evidence; they do not establish that you ran the code or reproduced the bug.

give it a repository boundary

name the repo in every routine, especially if your account can reach several. explain what your labels mean before allowing label changes. a report without reproduction steps should remain uncertain, rather than becoming a confident diagnosis. the issue triage routine is a useful next step.

keep discussion and tracking together

if the team plans in linear, let that tracker own priority. github can supply the issue and code context. a slack digest can cover discussion, but a suggestion in chat should not silently become a change to a release plan.