dusk botturn your bug notes into a github issue with ai
a useful bug report saves the next person a round of questions. give your bot the repository and what you saw.
it can file an issue with a title, body, labels and assignees. the repository must allow issues. creation is a write, so say "show me before you file it" when you want a review.
create an issue, in plain words
give the developer enough to start, without a follow-up interview. the bot needs the repository owner, name and issue title. add what happened, what you expected and the steps you actually tried. leave unknown details as questions.
labels, assignees and milestones are optional. github can quietly skip extras your account cannot set. open the finished issue to see which ones stuck.
a routine to copy
paste this into a chat with your bot
every friday at 4, read bug notes added this week to the booking-desk bug reports folder. use only notes marked ready for copperfinch/booking-desk.
- prepare a title, observed result, expected result and reproduction steps from each note
- search the repository for matching reports
- show any matches and proposed issues here
ask me before you change anything. create only the issues i confirm. don't invent steps or assign anyone. if a matching report exists, ask what to do. skip notes that already link to a filed issue.- when
- fridays at 16:00
- needs
- access to the bug reports folder; github read and write for issue search and creation in copperfinch/booking-desk
what comes back looks like this (an example)
issue proposal: booking confirmation loses the room name
repository: copperfinch/booking-desk
renata's note: choose a room, save a booking, reopen the confirmation.
expected: the selected room name stays visible.
actual: the room field is blank.
search found no matching report. waiting before creation.good jobs for it
- save the demo failure. turn your customer demonstration notes into steps someone can follow.
- make accessibility work concrete. describe the missing behaviour and exactly how you found it.
- fix a docs gap. file the small writing change in the repository that owns it.
- capture an agreed task. leave the deadline and owner blank unless someone chose them.
before it runs
dusk bot counts Create 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: public_repo, repo.
how to start
- name the repository exactly. connect github and give its owner and repository, not just an internal nickname.
- allow only needed actions. issue search and creation need read and write. read only cannot file anything.
- read the proposal first. tell it to wait for your confirmation before creating the issue.
- see what stuck. open the new issue and look for the labels, assignees and milestone you requested.
limits worth knowing
- issues must already work there. this action cannot create a repository or turn its issues on.
- success can hide skipped extras. github can file the issue while dropping labels, assignees or a milestone your account cannot set.
- creation doesn't pause by itself. keep an ask-first line in the routine if you want to review it.
- the issue starts the investigation. your evidence gives a developer somewhere to begin; filing alone neither reproduces nor fixes the bug.
the details it works from
| input | required | what it is |
|---|---|---|
repo | yes | The name of the repository, without the `.git` extension (case-insensitive). |
owner | yes | The GitHub account owner of the repository (case-insensitive). |
title | yes | The title for the new issue. |
body | no | The detailed textual contents of the new issue. |
labels | no | Array of label names to associate with this issue (generally case-insensitive). |
assignees | no | GitHub login names for users to assign to this issue. |
from composio's catalog for GitHub (action GITHUB_CREATE_AN_ISSUE, read 12 november 20264). your bot fills these in from what you tell it.
try it in 2 minutes
- give the repository owner and name
- describe one actual failure and its steps
- ask for an issue proposal without filing
- look for an existing report before confirming
quick checklist
- the repository has issues enabled
- the steps describe what someone really tried
- uncertain details remain questions
- the final issue has the extras you requested
mistakes people make
filing a polished guess
leave missing evidence as questions. tidy wording cannot replace a reproduction step.
treating a successful create as a complete setup
open the issue. labels and assignments can disappear without stopping creation.
questions
can it file an issue without assigning a developer?
yes, ownership can stay blank. only the title, repository owner and repository name are required. assignees are optional.
why did my new issue appear without its label?
github can quietly drop a label your account cannot set. creation can still succeed. open the issue and look at its labels.
sources
read next
a github bot that reads the work before you weigh inissues and pull requests, with context.
ask ai to add the right labels to a github issueconsistent labels start with exact names.
close a specific github issue after you confirm the outcomeclose the issue for the reason you chose.
claude connectors: connect the job you actually needpick a task before you connect an app.
triage a github issue when it opensa new report, with context for a maintainer.
write the github issue comment that moves things alongthe right comment on the right issue.
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].