GitHub announced updates to GitHub Copilot in Slack and Microsoft Teams on September 25, 2026. In the public preview, Copilot can use more conversation context when work begins in a collaboration thread, then link the resulting GitHub work back to that discussion.
In Slack, supported files, attachments, and message links can be used as context. In Teams, Copilot can use inline images, forwarded-message context, and channel and thread history. GitHub also says Copilot checks for similar issues before creating a new one and links created work to the originating discussion. See the GitHub announcement for the full release details.
What changed for collaboration-to-code workflows
- Slack can provide supported files, attachments, and message links as task context.
- Teams can provide inline images, forwarded-message context, and channel or thread history.
- Created issues and other work include direct links, with a path back to the source discussion.
- Users can choose a model for the next message and retain that choice through the conversation.
- GitHub also reports reliability fixes for longer-running and interrupted tasks.
These integrations remain a public preview for organizations on GitHub Copilot Business and Enterprise. GitHub notes that availability is rolling out gradually and usage is managed with existing Copilot entitlements and cloud-agent budgets.
Why this matters for QA engineers
QA evidence often starts in a defect report, a flaky-test thread, or a screenshot shared during triage. Richer conversation context can reduce re-explaining that evidence when an agent opens an issue or a pull request. It also increases the chance that irrelevant, sensitive, or contradictory messages shape the request. Treat the collaboration thread as an input surface for your test workflow, not just a notification channel.
GitHub’s Slack and Teams documentation says the agent captures the entire thread as context and stores that context in generated artifacts. In shared conversations, it creates artifacts under its app identity; repository rulesets can therefore require an additional approval before merge. Those details make provenance, permissions, and human review practical test targets.
A focused QA validation checklist
- Create controlled Slack and Teams threads with relevant, irrelevant, and sensitive-looking test data; confirm the agent’s task summary uses only the intended scope.
- Verify that the created issue or pull request links back to the right conversation and does not duplicate a known issue.
- Test direct-message versus shared-thread behavior, including the identity recorded on generated pull requests.
- Confirm repository write access, cloud-sandbox policy, and required approvals prevent unauthorized changes or merges.
- Exercise an interrupted or idle session and record the status, reconnect, and recovery behavior expected by your team.
Start with a non-production repository and a short-lived test channel. A useful acceptance criterion is simple: a reviewer should be able to trace each agent-generated change to the intended conversation, understand what context was used, and apply the same approval controls as any other proposed change.