From Slack thread to pull request

A bug report in Slack usually has enough context to start a conversation. It rarely has enough context to finish a pull request. Someone posts a screenshot, another person remembers a related change, and the reproduction steps end up six replies below the original message.

An agent can work from that discussion. It still needs a clear assignment and the correct repository. Before sending it off, spend a minute turning the conversation into a task someone can verify.

Pick the repository first

A channel often discusses several services. "The invoice filter is broken" could be the billing frontend, the API that serves it, or a shared component library. Name the repository before the agent edits anything, and check that name in whatever the agent replies with before it goes further.

Keep the reproduction in the request itself. A link to another channel or a private conversation is only useful if the agent can read it. If it can't, paste a sanitized reproduction into the assignment.

If you don't want to copy the thread into a task yourself, Hoplite's Slack integration starts the run from the thread. Route the channel to one repository explicitly for the first trial.

Put the acceptance check in the prompt

Suppose the report says that applying a filter on the invoices page clears the selected customer. That's a useful starting point. Add the conditions that distinguish a fix from a plausible diff.

An example request:

Investigate the invoice filter bug discussed in this thread. In the billing application, select a customer, then change the invoice status filter. The customer selection should remain active. Reproduce the problem with the sandbox's own seeded development data only; do not use production credentials or real customer data, and keep account details out of the pull request description and screenshots. Identify where the selection is reset and add a regression test. Keep the change limited to filter state. Open a draft pull request with the reproduction steps and test results. Ask before changing the API or database schema.

The stop condition is deliberate. A small UI bug should not turn into a billing redesign because the agent found untidy code nearby.

Review outside Slack

A chat thread is a fine place to see that work started and finished. It is a poor place to read a diff, a test log, or a screenshot sequence. For anything longer than a one-line fix, decide up front where the team reviews the result and put a link to it in the thread, so the reporter and the reviewer end up looking at the same evidence.

Sensitive actions may pause for approval. An unattended run started from Slack at 6 p.m. can be sitting on a permission prompt at 9 a.m., so check for pending approvals before assuming the agent got stuck on the bug.

Keep merging manual for the first trial, regardless of what the repository's defaults allow.

Repeat the reported steps

For the invoice example, read the regression test and repeat the original filter sequence against a running build. Check whether other filters still compose correctly. A test that only verifies the customer dropdown renders would miss the reported failure.

Ask the agent to distinguish checks it ran from checks it couldn't run. If the environment lacked development credentials for part of the flow, that belongs in the pull request description. The reviewer can then supply the missing verification without reconstructing the investigation.

Start with one bug already discussed in Slack and small enough to review in one sitting. Write the expected behavior, and inspect the first resulting diff before expanding the workflow to a busier channel.