From a Slack message to a draft pull request
Hand Jigward a bug in the thread where it was reported, and get a draft pull request and a report back in the same thread. What to set up, what Jigward does, and where you step in.
A bug usually turns up in a conversation. Someone posts a screenshot in the team channel, a few people agree it looks wrong, and the thread goes quiet until an engineer has time to look. This guide shows how to hand that bug to Jigward in the thread itself, and what comes back.
The example below is set at Orbit Cab, a made-up cosmo-taxi company. It shows the steps Jigward takes and what each one leaves behind. It is not a recording of a real Task.
Before you start
- Slack is connected. An admin installs Jigward’s Slack app in the organization’s workspace and approves it in Slack. One workspace works for one organization.
- The channel is named. The app is invited to the channel, and an admin names the channel on the integrations screen together with the Context Jigward works in there. A Context is one area of work, such as a product’s backend, with its repositories and Tasks. A channel that is not named is not answered.
- The repository is in that Context. It comes from the organization’s GitHub connection. If Jigward is still reading it when the Task needs a workspace, the Task waits and goes on by itself.
1. Ask in the thread
Reply in the thread where the bug came up, and mention Jigward:
Example request
@Jigward dispatch says rides to Moon Base 2 cost ten times more after midnight UTC. Can you find out why and fix it?
Jigward acknowledges the mention with a reaction, then reads the conversation around it: in a thread, its first message and up to the fifty-nine latest replies before the mention. What it reads there is context. Only the mention is a request.
2. Jigward takes it on as a Task
A mention ends one of four ways, always in the thread:
- a question is answered there, with no Task created;
- a request for work becomes a Task, the unit of work Jigward carries through to a report;
- a request to stop the thread’s Task stops it;
- when Jigward cannot tell which was meant, it asks once and waits.
Here it is a request for work. Jigward creates the Task in the channel’s Context, in the person’s own words, with the messages it read kept word for word under their authors. It replies that it created the Task, with its link. It never says the work is under way when the Task is only waiting its turn.
3. Jigward works on it
Jigward reads the repository first: its code, its conventions, its history, and what it already knows about the product. When the work needs a working copy, it takes an isolated workspace with the repository at the commit it last read.
For a bug, it writes a test that reproduces the bug and sees it fail, then fixes the code and sees the test pass. Before it proposes the change, it runs the repository’s own checks, the commands the repository’s CI runs on a pull request, so the pull request does not arrive red. It says tests passed only when a recorded run shows them passing.
Nothing is posted in Slack while it works. The Task on the web shows what it read, changed and ran.
4. If it has to ask, it asks in the thread
Jigward asks only when it cannot go on responsibly: the change would lose or rewrite data people already use, the request reads two incompatible ways, or it lacks access. The question appears in the thread, mentions the person who gave the Task, and offers two to four options as buttons.
Anyone who can write in the thread can answer with a button, or with a mention in their own words. The choice is kept on the Task under the name of the person who made it.
5. The report and the draft pull request
When the work ends, the report is posted in the thread, followed by links to the Task and to its pull request. It says what Jigward found, what it changed, what it decided and why, and how it checked. It carries Jigward’s own verdict, Done, Partly done or Blocked, which is Jigward’s word and not a check.
The change is a draft pull request on a branch of the Task’s own. Screenshots, a recording or files the work attached follow the report as files in the thread. Test output and logs stay on the Task.
6. You review and merge
The Task now waits as Awaiting code review. Review the pull request on GitHub as you would a colleague’s:
- Comment or request changes in a review, and the same Task continues on the same branch. Jigward answers each comment where it was left.
- Ask for more in the thread with another mention. It is added to the same Task, never a second one.
- Merge it when you are satisfied. Jigward never merges, and the thread is told when the Task is done.
- Stop it by asking Jigward in the thread, or from the web. Stopping keeps what was done and does not close the pull request.
Limits worth knowing
- Jigward reads nothing further back than those sixty messages.
- Anyone who can write in a named channel can give Jigward work, guests included. Name only channels whose people you are happy to have do that.
- Files posted in the thread are copies held by Slack. Everyone in the channel sees them, they follow the workspace’s retention, and they are not taken back if the Task is deleted. A screenshot of a page that shows a credential shows it there too.
- The workspace is not isolated yet. Repository code that runs there reaches the public internet directly. Isolating it is designed and not yet applied.