a jira assistant that explains what changed

what a bot can do in Jira

a status label is only the latest state. for a sprint or release review, ask the bot to read the issue and the available history together. the useful output is a list of changes and questions with issue references, not an unsupported judgement about whether a team will finish.

composio, the connection service dusk bot uses for apps, lists 146 Jira actions (catalog version 20261104_00, read 12 november 2026⁴). dusk bot treats 97 of them as reads, 2 as sends and the other 47 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 comment: it waits for your Allow unless you've given that bot a daily amount it may send alone.

connect Jira

1. open Connected apps in the sidebar.
2. pick Jira and sign in on Jira'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 Jira.
4. ask in plain words. reading and drafting happen freely; sending asks you first.

connect jira, choose the bot allowed to use it and start with reading. specify the project, board and sprint rather than asking for "our current sprint" without context. give the bot an existing jql filter if that is how your team defines a release or bug queue. have it confirm the issue set before scheduling.

routines to copy

use the same issue selection your team reviews, then ask one question about it. the schedules below gather evidence without moving work, notifying teammates or making promises about a release.

every weekday at 4, review the jira sprint i specified. use issue changelogs to identify recorded scope or status changes since the previous workday. separate additions, removals and unclear history. include issue keys and leave the sprint unchanged.

every wednesday at 10, search the jira bug queue with the jql i gave you. read the history and comments for issues that match our reopened-status rule. summarise the recorded reason for reopening and mark missing reasons as questions. do not assign blame or edit tickets.

every thursday at 2, review the jira issues selected by our release filter and the relevant project version. list unresolved work against the release checklist i supplied. read issue comments where the status is unclear. do not change versions, statuses or dates.

what it asks you first

a read-only jira bot cannot transition issues, assign work or create tickets. it can still inspect available transitions and bring you a proposal. permission to view a workflow does not include permission to move an issue through it.

the sending setting doesn't cover issue edits or transitions. if you enable them, write "ask me before you change anything" into the routine and restrict which actions it may call. adding a comment counts as a send. connected-app sends have a separate approval setting that asks by default, unless you give a daily allowance. a bot on Full access with no sending rule of its own may send up to 25 a day without asking, so set Ask every time for it.³ that setting is not a replacement for controlling issue changes.

what it cannot do

• transition an issue with read-only access, even if it can list the available transitions. a recommendation and a workflow change are separate jobs.
• infer a reopening reason that nobody recorded. comments and changelogs can provide evidence; an absent explanation should remain a question.
• treat a release filter as proof a release is ready. the routine checks the issues against the checklist you supplied and returns unresolved questions.
• inspect sprint changes on schedule while your desktop sleeps. local routines pause when the computer sleeps or dusk bot closes; dusk cloud can keep the review running.

use the workflow names your team uses

give the bot your actual status meanings and the jql you want it to start from. teams use different workflows, so "reopened" needs a rule rather than an assumption. inspect a first review against the issue histories before relying on the recurring note.

if implementation evidence also lives in github, connect it separately. an issue status alone should not be presented as proof that code shipped.

keep the question close to a decision

scope changes help a sprint lead plan a conversation. reopening reasons help choose a bug to investigate. release questions help an owner check a candidate. for a team working in linear, use its own issue tools; product managers can keep the review focused on the decision they need to make.