From “the list is wrong” to a change someone can review

A conversation is the starting point

A student film club runs a small equipment checkout site. After a busy Tuesday, someone posts in chat: “The microphones still show as available after checkout. Can we fix the list?” One member says refreshing makes it work. Another thinks the problem started when the club bought a second identical microphone. A third asks whether the site should stop people from reserving equipment that is already on loan. That thread contains a useful bug report, several guesses and a separate product decision.

GitHub’s November 6 release makes that kind of conversation a more direct starting point for code work. The company announced general availability of @GitHub in Slack and Teams, describing support for bug investigation, issues, changes and pull requests. Teams also gains Canvas for discussing plans, changes and previews. Generated issues and pull requests now identify the conversation and initiating username in their descriptions. These are product capabilities, not evidence that a thread’s requirements will be interpreted correctly.

GitHub’s Slack documentation makes a consequential detail explicit: the whole thread becomes context, and its content is stored in generated artifacts. That is a reason to make the conversation’s current decision easy to find. It is also a reason to avoid assuming that one tidy request cancels all the speculation sitting above it.

The film club does not need a long design document to use a chat-based coding assistant well. It needs a short account of what happened, what is still uncertain, and what a reviewer should be able to see after a change. A few minutes spent separating those things can give the eventual pull request a coherent purpose.

Source: GitHub: @GitHub in Slack and Teams is generally available and more ↗ · GitHub Docs: Integrating Copilot cloud agent with Slack ↗ · GitHub Docs: Best practices for using GitHub Copilot to work on tasks ↗

Turn recollections into one observable case

Start with the member who saw the problem and ask for the smallest sequence they can describe. In our fictional example, it could be: open the microphone list, check out microphone M12 to a member, return to the list without reloading the page, and see M12 still labeled available. The expected result is that the list shows M12 on loan. That is enough to identify an observable mismatch without deciding why it occurs.

Keep the refresh observation as evidence rather than a conclusion. “Reloading the page showed M12 as on loan” narrows the problem differently from “the database is fine.” The first describes what a person saw. The second asserts a cause that the report does not establish. A coding agent may investigate stored state, the page’s local data or a response that arrived late. Give it the observation and let the investigation distinguish them.

Ask what makes the two microphones distinguishable. If the club has individual asset numbers, use those numbers in the reproduction. “The microphone” could mean a model of microphone, one physical item or a grouped inventory count. A fix aimed at the wrong meaning might make the display look better while leaving individual records confusing. The report should name which object was checked out and which object stayed available.

Record the setting only as far as it helps recreate the case. Include the relevant page and whether the member moved through the site or used the browser’s back button. Avoid turning an uncertain memory into precise detail. If nobody remembers which route they took, say that and give the investigator two plausible paths to examine. A useful report can have unknowns; it becomes misleading when the unknowns disappear into confident prose.

Choose the decision that belongs in this change

The suggestion to block reservations for on-loan gear may be sensible, but it changes the club’s rules. Perhaps the club deliberately allows a reservation for next week while an item is on loan today. Perhaps the current reservation page has no dates. The stale availability label does not resolve that question.

Give the immediate task a boundary: after a successful checkout, the inventory list should display the item’s updated loan status without requiring a full page reload. Ask the investigator to report whether the same issue affects returns, but do not silently expand the task into rewriting the reservation process. The reviewer can decide what to do with any second finding.

GitHub’s guidance on cloud-agent tasks recommends a clear problem, a limited scope and complete acceptance criteria. For the film club, those criteria should be written in terms of the behavior people need. After a successful checkout, the member sees M12 on loan. If checkout fails, the page should not continue presenting a completed checkout. A different microphone remains available. Returning to the list through the normal navigation should show the same state as a fresh load.

These statements guide investigation without prescribing an unverified cause. “Invalidate the cache” may eventually be the right implementation. Putting that instruction at the top of the report could also steer attention away from a page that never uses the updated response. Keep a suspected fix in a clearly labeled note, with the reason someone suggested it. That preserves useful technical intuition while allowing the repository evidence to change the plan.

Give the agent a concise account of the thread

Before asking for implementation, post a settled summary in the thread. For this fictional club, the summary can describe the reproduction, the intended behavior and the remaining question about navigation. It can also say that reservation rules belong to a separate discussion. The summary is useful to a person who joins late as well as to the agent.

Use explicit verbs when reporting agreement. “Maya reproduced the stale label after checkout” is different from “Maya proposed changing reservations.” “The maintainer accepted the display fix for this task” is different again. A thread can contain all three without any contradiction. Trouble starts when a summary compresses them into “the team agreed to fix availability.”

Do not attribute consensus to silence. If the maintainer needs to decide whether checkout should update several open pages at once, name the question and leave it unresolved until someone answers. A chat assistant can generate a plausible interpretation quickly; that does not make the interpretation a club decision. For the small display bug, one page updating after its own completed action may be a sufficient target. Live updates across other devices could be a later feature.

If the thread is tangled enough that the summary keeps referring to old jokes, unrelated requests or contradictory examples, create a clean issue from the settled facts. Link back to the relevant conversation where appropriate, but make the issue understandable on its own. The goal is that a reviewer opening the repository a month later can recover the task without replaying the whole evening’s chat.

Keep the summary current as investigation proceeds. If the agent finds that the reproduction only occurs after using the back button, revise the reproduction and note the discovery. An updated account is more useful than keeping the original broad claim untouched while the code fixes a narrower case.

Read the plan as an interpretation of the request

A proposed implementation plan is the first chance to see how the assistant understood the work. In the club’s example, a plan to refresh the relevant inventory data after checkout is at least addressing the stated display problem. A plan to prevent every reservation on an on-loan item has crossed into the separate policy question. Catching that difference before the code change is reviewed can save everyone a confusing pull request.

Ask the plan to connect its proposed change to the reproduction. Which part of the application owns the status shown on the list? What happens after a checkout response comes back? What evidence would show that the proposed change addresses the navigation path in the report? These are investigation questions, not instructions to invent file names or claim that a test has passed.

A useful response may say that the cause is still uncertain and describe the next inspection. That can be more informative than an elaborate plan whose confidence comes from assumptions. If the agent offers several possible fixes, ask it to choose based on the code it finds and explain the choice briefly. The club needs a reviewable change, not a catalog of every technique that might update a web page.

Check the adjacent behaviors that could be disturbed. If the list shares its data with the return page, an update might affect both. Ask for verification of the relevant paths that exist in the repository. The eventual report should distinguish automated checks that actually ran, a manual walkthrough that someone actually performed, and any path that remains unverified. None of those outcomes should be filled in merely to make a pull request look complete.

Preserve the decision when the code leaves chat

The pull request should lead with the concrete trigger and resulting behavior. In the fictional case: checking out an item left its old availability label on the list until a page reload; the change updates that displayed status after a successful checkout. That gives a reader a before-and-after relationship to evaluate.

Then explain the relevant limit. If the change handles the current user’s page after checkout but does not push updates to another member’s open browser, say so in the description. That detail is useful because “availability is fixed” might otherwise imply a live inventory system. A precise account of the result protects the next maintainer from having to guess what was intended.

The new conversation attribution gives a reviewer a useful route back to the source discussion. It does not say who verified the reproduction, selected the final scope or reviewed the implementation. Those are separate contributions. A short factual note can name the member who supplied the example and the maintainer who settled the behavior, without turning a generated artifact into evidence that either person approved every line of code.

During review, compare the changed behavior with the agreed examples. Does M12 update? Does the untouched microphone retain its own status? What does a failed checkout look like? If the implementation introduces a broader mechanism, ask whether that mechanism is necessary for the accepted task. A small bug can justify a reusable improvement, but the reviewer should understand the connection.

Finally, return a brief result to the original conversation. Link the artifact and describe what the change covers, including any unresolved follow-up. If investigation disproved the initial explanation, record the finding plainly rather than editing the history into a story where everyone knew the cause all along. Future members will learn more from an accurate report.

Chat can be an efficient place to begin code work because the people who noticed the problem are already there. The practical skill is carrying their observations into a specification that another person can inspect. Keep observations distinct from guesses, decisions distinct from suggestions, and verification distinct from plans. Then a conversational coding tool has a clear task to work on and a clear result for the club to review.