A lot of development work starts before anyone opens an IDE.
A developer reports a bug in Slack. A team discusses the problem in Microsoft Teams. Someone shares an error message, a screenshot, or a GitHub issue. Another developer explains what should be changed.
Normally, the next step is to leave that conversation, open GitHub, find the repository, inspect the issue, and start working on the code.
GitHub Copilot can now take part in that workflow directly from Slack and Microsoft Teams.
The GitHub integration allows developers to mention @GitHub in a conversation and use Copilot cloud agent to investigate problems, plan work, create issues, make code changes, and open pull requests. The agent can use the surrounding conversation as context instead of requiring the developer to copy everything into another tool.
The important part is not simply that Copilot is available inside Slack or Teams.
The useful part is the connection between the conversation and the repository.
Why This Matters for Development Teams
Consider a normal bug discussion.
A developer posts:
The checkout API is returning 500 when a customer has no saved address.
Someone replies:
Looks like the address service is returning null.
Can someone check the validation path?
Another developer asks:
Can we fix this and add a regression test?
In a traditional workflow, someone has to take that conversation and manually turn it into development work.
That usually means:
Slack / Teams
|
v
Understand the problem
|
v
Open GitHub
|
v
Find repository
|
v
Create issue
|
v
Open repository
|
v
Investigate
|
v
Make changes
|
v
Create PR
With GitHub Copilot integrated into the conversation, part of that process can happen without leaving Slack or Teams.
For example, a developer can ask:
@GitHub Investigate this checkout error in the backend repository.
Copilot can use the conversation as context, investigate the repository, and continue the work through a cloud agent session.
That removes some of the context switching that normally happens between team communication and implementation.
What GitHub Copilot Can Do From Slack and Teams
The integration is more than a chatbot that answers coding questions.
GitHub's current integration allows Copilot cloud agent to work with the development process itself.
Depending on the setup, developers can use it to:
Investigate bugs
Research repository code
Plan changes
Create GitHub issues
Update issues
Implement code changes
Create pull requests
Investigate failed workflows
Work across multiple repositories
Continue work asynchronously
GitHub also supports choosing models, connecting MCP servers, and using Copilot Memory in these integrations.
That makes the integration much closer to an engineering assistant than a simple question-and-answer bot.
How Copilot Uses the Conversation
Context is the part that makes the integration useful.
Suppose a team is discussing a production problem in a Slack thread:
Developer 1:
The product API is timing out after the latest deployment.
Developer 2:
It looks like the inventory service is taking too long.
Developer 3:
The timeout happens only for products with multiple warehouses.
Developer 1:
Can someone investigate the backend and see where this starts?
If a developer mentions @GitHub from that conversation, Copilot can use the thread as context for the task.
GitHub states that the entire Slack thread can become part of the agent's decision-making context. The generated artifacts can also retain that context.
This means developers do not necessarily need to rewrite the entire problem in a new prompt.
The conversation itself can become part of the engineering context.
That is useful, but it also creates an important security consideration.
Be Careful About What You Discuss in the Thread
The same context that makes Copilot useful can also make it important to think about what information is present in a conversation.
If Copilot is invoked in a Slack thread, the integration can use the conversation as context.
So avoid putting unnecessary secrets, credentials, private customer information, or sensitive operational details into the thread.
GitHub specifically notes that the entire thread can be captured as context for the agent and stored in generated artifacts. If you want to limit the context, using a direct message with the GitHub app provides a narrower interaction.
This is a practical difference between:
Private conversation
|
v
Limited context
and:
Large team thread
|
v
More context
|
v
More information available to the agent
More context is not automatically better.
The useful context is the context the agent actually needs to complete the task.
Using @GitHub in Slack
The Slack integration is available through the GitHub app.
After connecting the app to GitHub, a developer can open a direct message or mention @GitHub in a thread or channel.
For example:
@GitHub Investigate the failed checkout workflow in
my-org/store-api and explain the likely cause before changing code.
GitHub can start a cloud agent session and work on the task asynchronously. Once the work is complete, it can provide a summary and links to the resulting artifacts.
The workflow can therefore look like:
Slack discussion
|
v
@GitHub
|
v
Copilot investigates
|
v
Code changes
|
v
Pull request
|
v
Developer review
The developer does not need to keep the Slack window open while the agent works.
Slack Code Channels
GitHub's Slack integration also creates a dedicated code channel for a Copilot task.
This channel is associated with the specific agent session and can contain information about the repositories, branches, pull requests, status, and model being used.
This is useful for teams because the development task does not get mixed into the original general conversation.
Imagine a team channel with several unrelated discussions:
#backend-team
Checkout timeout
Deployment problem
Database migration
New API design
Customer bug
Release planning
Starting an agent session creates a separate workspace for the coding task.
That gives the team a cleaner place to continue steering the work.
Using GitHub Copilot in Microsoft Teams
The Teams integration follows a similar idea.
Developers can mention @GitHub in a Teams conversation, channel, or thread and ask Copilot to investigate, plan, or implement work.
The integration can use the thread and GitHub context to understand the task. Developers can also collaborate with the agent by adding information, correcting assumptions, and continuing the task.
For example:
@GitHub Investigate why the orders API integration test is failing.
Use the backend repository and create a PR if you find a safe fix.
Copilot can then investigate the repository and continue the task through its cloud environment.
This is particularly useful for teams that already use Teams as the main place for engineering discussions.
Turning a Teams Notification Into a Code Change
One useful workflow starts with a GitHub notification.
Suppose a bug report is created in GitHub.
The team receives the notification in Teams.
Instead of opening GitHub immediately, a developer can reply to the notification and mention @GitHub.
The task can then move through:
GitHub issue
|
v
Teams notification
|
v
@GitHub
|
v
Investigation
|
v
Code change
|
v
Pull request
GitHub's Teams integration supports this type of workflow, including delegating tasks from GitHub notifications.
This is a practical example of where the integration can save time.
The team does not have to manually transfer the issue from one system into another.
Copilot Can Work Across Multiple Repositories
Real applications rarely live in a single repository.
A frontend may live in one repository.
The backend may be in another.
Infrastructure may be somewhere else.
A bug can cross all three.
GitHub now supports multi-repository work in Slack and Teams.
For example, a developer could ask:
@GitHub Investigate this login issue using the frontend
and authentication repositories. If the backend needs a fix,
open a PR there.
Copilot can work across multiple repositories within the same conversation when the required permissions and configuration are available.
This is more useful than forcing developers to switch between separate conversations for every repository.
It also better matches how production systems are actually structured.
Repository Permissions Still Matter
Being able to mention @GitHub does not mean every person in the conversation can make changes to every repository.
GitHub applies repository permissions to agent actions.
In Slack, users need write access to the repositories selected for a session in order to trigger Copilot to make changes or steer the session. Other participants can still contribute context to the conversation.
Teams follows a similar permission model.
This is important for organizations because a developer should not gain repository write access simply because they are participating in a Slack or Teams conversation.
The conversation and repository authorization are separate concerns.
A useful mental model is:
Conversation access
|
v
Can participate in discussion
Repository permission
|
v
Can trigger or control code changes
Both need to be considered.
Pull Requests Created From Shared Conversations
There is another detail that teams using repository rulesets should understand.
When Copilot creates a pull request from a shared Slack or Teams context, the PR can be created under the GitHub app's identity rather than a particular person's identity.
GitHub notes that repository rulesets can therefore require an additional approval before merging when the repository already requires at least one approval.
This is not a reason to avoid the integration.
It is something to account for in your branch protection and review process.
For example:
Slack discussion
|
v
Copilot changes code
|
v
PR created by GitHub app
|
v
Required review
|
v
Additional approval if rules require it
|
v
Merge
The important point is that agent-generated code should still go through the same engineering controls as developer-generated code.
The Cloud Sandbox Matters
Copilot cloud agent does not simply execute arbitrary commands on a developer's local machine.
The work runs asynchronously in a secure cloud sandbox. GitHub describes the sandbox as the environment where Copilot can investigate repositories, make changes, and validate its work.
This creates a useful separation:
Developer workstation
|
| Conversation
v
Slack / Teams
|
v
Copilot cloud agent
|
v
Secure cloud sandbox
|
v
Repository changes
|
v
Pull request
The developer can continue working while the agent handles the delegated task.
The result can then be reviewed in GitHub, a terminal, an IDE, or another supported Copilot surface.
Start With Small, Well-Defined Tasks
The integration is not a reason to hand over an entire application to an agent.
It works better when the task has a clear boundary.
For example:
Good task:
Investigate why the order API returns 500 when
customer address is missing. Add a regression test
and create a PR if the fix is isolated.
This gives the agent:
A problem
A starting point
A repository
A clear expected outcome
A reasonable boundary
Compare that with:
Bad task:
Fix the backend.
The second request leaves too many decisions open.
The agent may investigate several unrelated areas or make changes that are difficult to review.
A good engineering task is a good agent task.
Use the Conversation for Context, Not for Secrets
A useful pattern is to keep the conversation focused on engineering information.
For example:
Problem:
Checkout fails when the address is missing.
Observed behavior:
API returns HTTP 500.
Expected behavior:
Return validation response.
Scope:
Checkout API only.
Testing:
Add regression test.
This gives Copilot enough context to investigate without turning the conversation into a place where credentials or unrelated customer information are copied.
The goal is to give the agent the information needed to reason about the problem.
Review the Agent's Work Like Any Other Pull Request
The biggest mistake teams can make is treating an AI-generated pull request differently from a normal pull request.
The code still needs review.
Check:
Does the fix actually solve the problem?
Were unrelated files changed?
Are tests meaningful?
Could the change break existing behavior?
Are security checks passing?
Are database changes safe?
Are API contracts affected?
Does the implementation follow project conventions?
The fact that the work started in Slack or Teams does not change the review standard.
The agent should make implementation easier, not lower the engineering bar.
A Practical Workflow for Teams
A team can introduce the integration gradually.
Step 1: Connect GitHub to Slack or Teams
Install the GitHub app and connect the required GitHub account or organization.
Step 2: Configure Repository Access
Decide which repositories the integration can work with.
Do not give the integration unnecessary access.
Step 3: Start With Investigation Tasks
Ask Copilot to investigate bugs or explain failed workflows before allowing it to make larger changes.
For example:
@GitHub Investigate this failed test and explain the likely cause.
Do not change code yet.
This is a good way to evaluate how well the agent handles your repository.
Step 4: Move to Small Code Changes
Once the team is comfortable with the workflow, delegate small fixes.
@GitHub Fix the null handling in ProductService
and add a regression test.
Step 5: Require Pull Request Review
Keep normal branch protection and review rules.
Do not merge agent-generated code automatically simply because the agent reports that its tests passed.
Step 6: Expand to Larger Tasks Carefully
Once the workflow is reliable, teams can use it for more complex investigations and multi-repository work.
The key is to increase scope gradually.
Slack and Teams Are Not the Same as the IDE
Developers should not think of Copilot in Slack or Teams as a replacement for the IDE.
The two environments serve different purposes.
The IDE is where developers usually perform close, interactive code work.
Slack and Teams are where teams discuss problems, decisions, incidents, and work.
The integration connects those two parts.
Slack / Teams
Team discussion
|
v
Copilot
Investigation + planning
|
v
GitHub
Issues + PRs
|
v
IDE / Terminal
Detailed review and development
This division makes more sense than trying to perform every coding task inside a chat application.
Common Mistakes
Treating Copilot Like a Chatbot
The integration can create issues and pull requests and perform development tasks. It is not limited to answering questions.
Giving Vague Requests
“Fix the backend” gives the agent too much freedom.
Describe the problem, expected behavior, repository, and desired result.
Sharing Sensitive Information
Remember that conversation content can become part of the agent context.
Do not copy secrets or unnecessary sensitive data into the conversation.
Skipping Code Review
Agent-generated code still needs human review.
Giving Excessive Repository Access
Configure the integration around the repositories the team actually needs.
Ignoring Shared-Context Permissions
A person participating in a conversation does not automatically have the same permissions to control the agent or modify repositories.
Treating a Successful Agent Run as Proof of Correctness
An agent can complete its task and still misunderstand the business requirement.
Tests and review remain necessary.
Where This Fits Best
The Slack and Teams integration is particularly useful for work that naturally begins as a conversation.
Examples include:
Production incident
|
v
Investigation
Bug report
|
v
Reproduction + fix
Failed CI build
|
v
Investigation + PR
Feature discussion
|
v
Implementation plan
Code maintenance request
|
v
Issue + pull request
These are situations where the team already has the necessary context in the conversation.
Instead of copying that context into another tool, Copilot can use it directly.
Final Checklist
Before using GitHub Copilot in Slack or Teams for development work, make sure your team has:
GitHub integration installed
Copilot access configured
Required repository permissions
Clear repository ownership
Branch protection and review rules
A process for reviewing agent-generated pull requests
A policy for sensitive information in chat
A clear approach for handling secrets
Appropriate monitoring of agent-created work
The technical setup is only part of the process.
The bigger change is deciding how your team wants conversation-driven development to work.
Summary
GitHub Copilot in Slack and Teams connects team discussions with actual development work. Developers can investigate problems, create issues, make code changes, and open pull requests without leaving the conversation.
The best results come from giving Copilot clear tasks, limiting repository access, keeping sensitive information out of conversations, and reviewing every code change before it is merged.
Join the conversation! Your thoughts help the community grow.