Inside this story Context & sources

This article links to 2 sources. Source links are provided below so you can inspect the evidence yourself.

  • One conversation can ask about work across repositories.
  • The announcement specifically assigns shared message context to Slack.
  • Try a bounded catch-up and check it against the original records.

One conversation, several projects

GitHub’s 15 October update lets Copilot in Slack and Microsoft Teams answer questions across several repositories in one conversation. A repository is a project’s tracked collection of code and related files. GitHub gives examples spanning open pull requests, merged work and issues that involve both frontend and backend projects. [1]

For a small South African software team, our interest is the handover between projects. A customer-facing screen and the service behind it may live in different repositories, while the discussion happens in one channel. Our view is that a useful summary should make those project boundaries easier to follow, especially for the person picking up the work later.

The thread becomes part of the brief

GitHub also says Copilot can use shared Slack messages and threads as context. That is a Slack-specific statement in the announcement; it should not be read as a promise of identical message-context behaviour in Teams. The company also reports reliability improvements, which we have not independently measured. [1]

We would begin a trial with one question about two named repositories and a clear time window. Ask for the underlying pull requests or issues alongside the summary, then open a few of those records. Check which project each item belongs to, what actually changed and whether the response separates completed work from work still waiting. This is a suggested evaluation, not a test we have performed.

Check the setup before the request

GitHub’s Slack guide still labels Copilot there a public preview. It says a workspace administrator must first install the GitHub app, after which users connect their own GitHub accounts. The guide describes teammates adding context, correcting assumptions and reviewing the resulting work together. This is existing product guidance, not another 15 October announcement. [2]

That setup deserves a place in a team’s trial notes. Record which workspace and repositories the request concerns, who will check the response and where the original records can be found. A successful demonstration in somebody else’s workspace would not tell us what is available in ours. We have not verified South African adoption, local availability conditions or any particular organisation’s configuration.

A useful summary has a clear boundary

Our preferred first task would be a short, bounded catch-up rather than an open-ended request to change several projects. Keep the question and the checked answer together. If an item is missing, narrow the request and compare again, recording the gap rather than quietly filling it from memory.

The appeal of this update is a conversation that can follow work across project boundaries. The practical measure, in our view, is whether a teammate can trace that conversation back to the right records and continue with a clear understanding of what remains. A fluent recap alone would not answer that question.

Sources & further reading

1. GitHub’s 15 October Slack and Teams update

Dated GitHub announcement. Describes multi-repository questions, Slack context and claimed reliability improvements; not independent testing.

2. GitHub Docs: using GitHub in Slack

Undated guide, read 16 October. Public-preview status, setup and collaboration context from the same company, not independent corroboration.

AI-assisted research and writing, with a separate source-checking pass by the same Codex assistant. Both sources are GitHub material on distinct domains, not independent corroboration. Practical evaluation suggestions are our interpretation. No hands-on, measured reliability or South African rollout result claimed.

THE OPEN TABStay curious. Keep reading.