Introduction
A lot of software development starts in a Slack conversation.
Someone reports a bug. Another developer explains what might be causing it. A third person suggests a fix. Then somebody has to take that conversation, turn it into a GitHub issue, open the repository, understand the code, make the change, run tests, and create a pull request.
That gap between "we should fix this" and "here is the pull request" is exactly where the GitHub Copilot integration with Slack becomes interesting.
GitHub's Copilot cloud agent can now be used from Slack conversations to investigate problems, plan work, write code, create issues, and open pull requests using conversation context. The integration is currently in public preview and is available with paid Copilot plans.
The important idea is not simply bringing an AI chatbot into Slack. It is creating a workflow where a team conversation can become the starting point for an actual software-development task.
What Is GitHub Copilot in Slack?
The GitHub integration for Slack connects Slack conversations with GitHub Copilot cloud agent.
Developers can interact with the GitHub app through a Slack thread or direct message and ask Copilot to perform development work.
For example, a conversation might look like this:
Developer A:
The Orders API occasionally returns a 500 when the inventory
service takes too long to respond.
Developer B:
It looks like the timeout isn't being handled correctly.
Developer C:
Can we add retry handling and tests?
Developer A:
Yes, let's fix it in the orders-api repository.
Instead of manually copying the discussion into a GitHub issue, a developer can ask:
@GitHub Investigate the Orders API timeout issue.
Implement a safe retry strategy for transient inventory failures,
add tests, and create a pull request in orders-api.
Copilot can use the conversation as context, investigate the repository, work asynchronously in a cloud sandbox, make changes, run validation, and return the resulting artifacts.
That creates a much shorter path:
Slack Conversation
|
v
@GitHub
|
v
Copilot Cloud Agent
|
+--> Understand Context
|
+--> Investigate Repository
|
+--> Plan
|
+--> Implement
|
+--> Test
|
v
Pull Request
|
v
Human Review
Why This Workflow Matters
Traditional development tools generally start after the requirement has already been formalized.
The real work often begins earlier.
A developer might discover a problem during a Slack discussion, and that conversation contains useful information that never makes it into the eventual issue.
For example:
Slack
"This happens only when inventory times out."
GitHub Issue
"Fix Orders API error handling."
Code
Developer investigates the timeout behavior again.
The original technical context has been lost.
With an agentic Slack workflow, the conversation itself can become part of the development context.
That means the agent may have access to:
The original problem description
Technical observations
Team decisions
Constraints discussed in the thread
Suggested implementation approaches
Repository information
Follow-up corrections
GitHub describes this as keeping collaborative decisions connected to the resulting code and artifacts.
How to Start a Copilot Session in Slack
The basic workflow is straightforward.
First, the GitHub integration must be installed in the Slack workspace and connected to a GitHub account.
Then a developer can open a direct message with the GitHub app or mention @GitHub in a Slack thread.
For example:
@GitHub Investigate the timeout handling in
octo-org/orders-api.
Add tests for transient failures and create
a pull request against the develop branch.
GitHub also supports specifying the repository and branch naturally within the request.
A default repository can be configured for a Slack channel. If no repository or branch is specified, Copilot can use the channel's configured repository and its default branch.
From Conversation to Code
Let's consider a practical .NET example.
Suppose a team has an API that calls an external inventory service.
The discussion might be:
@GitHub
The Orders API fails when the inventory service has
a temporary timeout.
Please:
- Find the inventory-service client.
- Check whether resilience handling already exists.
- Add retry behavior only for transient failures.
- Do not retry authentication or validation failures.
- Add tests for successful retry and exhausted retries.
- Follow existing project conventions.
- Run the relevant tests.
- Create a pull request.
This is much better than:
@GitHub Fix the inventory API.
The first request provides enough information for an agent to understand both the desired behavior and the boundaries of the change.
For example, if the project already uses .NET resilience features, the agent might produce code conceptually similar to:
builder.Services
.AddHttpClient<IInventoryClient, InventoryClient>()
.AddStandardResilienceHandler();
The exact implementation should always depend on the repository's existing architecture and dependencies. The goal is not to force a particular code pattern, but to ask the agent to inspect before modifying.
Slack Code: A Dedicated Workspace for the Agent Task
One interesting part of the Slack integration is the creation of a dedicated Slack Code channel for an agent task.
When Copilot is asked to perform a coding task, it creates a code channel where the developer and optionally teammates can continue working with the agent.
The channel displays information such as:
Repository
Branch
Issue or pull request
Session status
Model being used
GitHub describes these code channels as being intended for one session at a time, with one channel per task. After the task is finished, the channel can be archived while its history remains searchable.
This is useful because the original Slack discussion and the active coding session serve slightly different purposes.
Original Slack Thread
|
| Requirement + Discussion
v
Agent Session
|
v
Slack Code
|
+--> Steering
+--> Clarifications
+--> Progress
|
v
Pull Request
Steering the Agent During Development
Agentic development does not mean sending one prompt and disappearing.
A developer can continue providing instructions.
For example:
@GitHub
The implementation looks good, but don't introduce
a new retry library. Use the resilience approach
already used by the Payments service.
Also add a test for authentication failures.
This kind of feedback is valuable because the first implementation may technically work but still violate architectural conventions.
The team can therefore treat the agent more like a development collaborator than a one-shot code generator.
Creating GitHub Issues From Slack
The workflow is not limited to pull requests.
Copilot can also create GitHub issues from Slack conversations.
For example:
@GitHub
In octo-org/orders-api, create a feature request
to add request correlation IDs to all external
service calls.
Copilot can create the issue and return a link to it. It can also create multiple related issues, including parent-child relationships, when requested.
This makes Slack useful earlier in the development lifecycle:
Idea
|
v
Slack Discussion
|
+----> GitHub Issue
|
+----> Investigation
|
+----> Implementation
|
v
Pull Request
Security: The Part Developers Should Not Ignore
This integration introduces an important security consideration.
When Copilot is invoked in a Slack thread, the entire conversation can become context for the agent. GitHub notes that this context can also be stored in artifacts generated by the agent.
That means developers should think carefully about what they put into shared conversations.
Consider this thread:
Production incident
|
+-- Customer information
+-- Internal URLs
+-- Temporary credentials
+-- Architecture discussion
+-- Error messages
+-- Final implementation decision
Sending the entire thread to an AI agent may provide more context than the task actually needs.
For focused tasks, a direct message to the GitHub app can provide a narrower context boundary. GitHub specifically recommends using a direct message when you want to limit the amount of conversation context provided to Copilot.
Never treat Slack as a safe place to paste secrets simply because the task is internal.
Permissions and Identity
Permissions become particularly important when an AI agent can modify repositories.
GitHub states that users need write access to a repository to trigger Copilot cloud agent to make changes. Other participants can still contribute context to the conversation.
There is also an important distinction between direct and shared interactions.
In a direct message, Copilot can perform actions using the permissions of the user's linked GitHub account.
In a shared Slack context, such as a group thread or channel, Copilot creates artifacts under its app identity rather than the individual user's identity.
This matters for repository rulesets.
For example:
Slack Team
|
v
Copilot
|
v
Pull Request
|
v
Repository Rules
|
+--> Required Review
+--> CI Checks
+--> Security Checks
|
v
Merge
Repository protections should remain in place rather than being relaxed because an AI agent created the pull request.
Direct Message vs Shared Channel
The two approaches serve different purposes.
| Area | Direct Message | Shared Channel / Thread |
|---|
| Context | More focused | Entire conversation can be used |
| Collaboration | Mainly requester + agent | Team + agent |
| GitHub identity | User's linked account | Copilot app identity |
| Best for | Focused tasks | Collaborative work |
| Context control | Better | Requires more care |
| Team visibility | Lower | Higher |
A direct message is often preferable for a narrowly scoped engineering task.
A shared thread is more useful when the team needs to collectively steer the work.
Advantages
Less Context Switching
Developers can move from discussion to implementation without manually recreating the entire requirement in another tool.
Better Preservation of Team Context
Technical decisions made during a Slack discussion can remain available to the agent instead of being lost during the transition to a GitHub issue.
Asynchronous Development
Copilot cloud agent works in a secure cloud sandbox and can continue working while developers focus on other tasks. Results can then be reviewed in Slack, GitHub, a terminal, or a code editor.
Collaborative Agent Steering
Multiple team members can provide corrections, additional requirements, and technical context during the task.
Faster Issue Creation
Teams can convert discussions into structured GitHub issues without manually rewriting the entire conversation.
Disadvantages and Limitations
Public Preview
The Slack integration is currently in public preview, so its behavior and capabilities can change.
Conversation Context Can Be Too Large
A long Slack thread may contain unrelated discussions or information that should not be part of an engineering task.
AI-Generated Code Still Needs Review
The agent can write code and run tests, but the pull request still needs normal engineering review.
Permission Configuration Can Be Complex
Organizations may need to configure Slack app access, GitHub permissions, Copilot policies, cloud sandboxes, repository access, and repository rulesets.
Not Every Task Should Be Autonomous
High-risk changes such as authentication, authorization, financial calculations, infrastructure changes, and production configuration should receive stronger human oversight.
Common Mistakes
Mistake 1: Using Vague Prompts
Avoid:
@GitHub Fix this.
Prefer:
@GitHub Investigate the timeout in Orders API.
Use the existing resilience approach, add tests for
transient and permanent failures, and create a PR.
Mistake 2: Giving the Agent an Entire Unrelated Conversation
A busy channel can contain hundreds of messages.
If only five messages are relevant to the task, a focused thread or direct message is usually a better starting point.
Mistake 3: Skipping Acceptance Criteria
Tell the agent what "done" means.
For example:
Done means:
- Existing tests continue to pass.
- New retry scenarios are covered.
- No new dependency is introduced.
- Authentication failures are not retried.
- Pull request contains a clear summary.
Mistake 4: Treating the Pull Request as Automatically Approved
A generated PR is still a PR.
Review the code, tests, dependencies, security implications, and architectural impact before merging.
Troubleshooting
| Problem | What to Check |
|---|
| GitHub app does not respond | Verify the GitHub integration is installed |
| Copilot cannot modify code | Check write access to the repository |
| Wrong repository used | Specify the repository or configure the channel default |
| Agent cannot start | Check Copilot plan and cloud sandbox availability |
| Agent receives irrelevant information | Use a focused thread or direct message |
| PR cannot merge | Check repository rulesets and required approvals |
| Implementation ignores conventions | Explicitly mention repository standards and constraints |
| Task becomes too broad | Split it into smaller agent tasks |
GitHub's documented prerequisites include a GitHub account with a paid Copilot plan, a Slack workspace, the GitHub integration for Slack, and enabled cloud sandboxes for Copilot cloud agent. Organizations may also need administrators to enable the relevant Copilot and sandbox policies.
Measuring Whether the Workflow Actually Helps
It is tempting to assume that adding an AI agent automatically makes a development team faster.
A better approach is to measure the workflow.
For example, teams can track:
| Metric | What It Tells You |
|---|
| Discussion-to-PR time | How quickly an idea becomes implementation |
| Review iterations | How much rework the agent's output requires |
| Failed CI runs | Quality of initial implementation |
| PR rework | How much code needs correction |
| Escaped defects | Whether automation affects production quality |
| Agent task completion | Which task types work well with agents |
The goal should not be "maximize AI-generated code."
A better goal is:
Reduce unnecessary engineering friction while maintaining code quality and security.
Best Practices for Teams
Start With Low-Risk Tasks
Good starting points include:
Small bug fixes
Test additions
Documentation changes
Simple refactoring
Repository maintenance
Isolated feature work
Keep Tasks Small
A focused task gives the agent a clearer objective and makes the resulting pull request easier to review.
Define the Expected Behavior
Include requirements, constraints, test cases, and the definition of done.
Protect the Repository
Continue using:
Branch protection
Repository rulesets
Required reviews
CI checks
Security scanning
Dependency controls
Be Careful With Slack Context
Before invoking Copilot from a shared conversation, ask whether the entire thread really needs to become part of the agent's context.
Keep Humans in the Review Loop
The best model is not:
Slack → AI → Production
It is:
Slack
↓
AI Agent
↓
Pull Request
↓
Automated Validation
↓
Human Review
↓
Production
Conclusion
GitHub Copilot in Slack is useful because it brings software development closer to where many engineering discussions already happen. A bug can be discussed in Slack, the team can provide context, Copilot can investigate the repository and work on the change, and the result can come back as a GitHub issue or pull request. The biggest benefit is not that developers no longer need their IDEs. It is that they spend less time moving information from one tool to another. At the same time, this workflow should be introduced carefully. Good prompts, focused conversations, repository permissions, automated checks, and normal human code review are still important. Used that way, Copilot in Slack can become a practical bridge between team conversation and actual software delivery, rather than just another place to ask an AI coding question.