GitHub Copilot pilot
GitHub Copilot rollout: from autocomplete to a shared agent configuration in your repo.
A GitHub Copilot rollout starts with a pilot: a shared agent configuration in one repo and a written go/no-go decision against agreed criteria.
The offer: a pilot for one team in one repo, ending in a written go/no-go decision against criteria set down before kickoff. We agree time and cost in writing before we start. A wider rollout is priced separately, and only after a go decision.
- .github/copilot-instructions.mdrepository-wide instructions
- .github/instructions/path-specific instructions
- AGENTS.mdagent instructions
- .github/agents/agent profiles
- .github/skills/team procedures
- .github/hooks/checks that run on events
- .github/workflows/copilot-setup-steps.ymlcloud agent environment
- .github/CODEOWNERSreview of configuration changes
The licences are there, but everyone sets up the agents their own way
Your company pays for GitHub Copilot, or your developers use it on their own plans. In practice the team mostly uses autocomplete, and each developer switches on and configures the agents alone. That means agent mode in the IDE, Copilot CLI, Copilot code review and Copilot cloud agent (formerly Copilot coding agent), which works in the cloud on GitHub and can open its own PRs. Once an agent changes code the whole team answers for, the missing shared rules show up in code review and in the questions your security team asks.
- The repo tells the agent nothing
- With no instructions in the repo, each developer explains project conventions, how to test and which areas are off limits to the agent separately, or not at all.
- Everyone works on different settings
- One developer uses the organisation’s plan, another a personal one, and each has different models, MCP servers and tools. The same task runs differently for each of them.
- Nobody knows what the agent can reach
- There is no single place that shows which tools, MCP servers and internet addresses the agent can reach in a given repo.
- Security questions nobody can answer
- Your security team asks about data, permissions and change control, and nobody can answer for the whole team.
Why run a pilot when GitHub publishes guidance?
GitHub publishes rollout guidance, including a tutorial on piloting a new feature or model in an enterprise. We do it in your repo, with your team, and finish with a written decision on whether to go further.
The pilot
A GitHub Copilot rollout starts with a pilot
The pilot is the first step of a rollout, not the whole rollout. We work with one team in one repo. Each step shows what Aurora AI does, what your team brings and what we check.
- Team
- One team that already has access to GitHub Copilot
- Repo
- One repo on GitHub, chosen together with you
- Ends with
- A written go/no-go decision against criteria set down before kickoff
- Time and cost
- Agreed in writing before kickoff
Diagnosis
Diagnosis and decision criteria
We look at which features your developers use today and on which plans, pick the team and repo, and write down the decision criteria.
- Aurora AI
- Talks to the developers, reviews their settings and the organisation’s current policies, then proposes the team, the repo and the go/no-go criteria.
- Your team
- The lead names the team, the repo and the person who will make the final decision. Developers show how they work with the agents today.
- We check
- The go/no-go criteria are written down, and the person who will decide accepted them before kickoff.
Configuration
A shared configuration in the repo
Working rules, roles and the agents’ tools go into the repo: repository-wide and path-specific instructions, AGENTS.md, agent profiles, skills, hooks and the cloud agent’s environment.
- Aurora AI
- Prepares the configuration from the diagnosis and submits every change as a PR.
- Your team
- Developers review every PR and decide what goes into the repo and what needs rework.
- We check
- The configuration lives in the repo, and every change to it has passed team review in a PR.
Tasks
Real work from the backlog
The team works with the agents on real tasks from the current backlog: in the IDE, in the terminal and on GitHub, where the cloud agent prepares a change on its own branch and can open a PR.
- Aurora AI
- Pairs with developers and adjusts the configuration where it gets in the way or something is missing.
- Your team
- The team picks tasks from the current backlog, hands some of them to the cloud agent, and reports where the configuration helps and where it slows work down.
- We check
- PRs prepared by the agent get the same code review as all other work, and configuration fixes go through a PR.
Governance
Governance and security
On top of the configuration in the repo, we add organisation policies, a PR gate and answers for your security team.
- Aurora AI
- Proposes organisation policies: available features, models and MCP servers, content exclusions and budgets. Sets up the PR gate and the cloud agent’s access to the internet and MCP servers, then writes down answers for the security team, including where content exclusions do not apply, for example in agent mode in VS Code.
- Your team
- Your organisation admins put the policies in place, and the security team asks its questions and assesses the answers. Licences stay on your organisation’s Copilot Business or Enterprise plan.
- We check
- The agent’s access to the internet and MCP servers matches the agreed list, no agent PR reaches the main branch without human review, and the security team has its answers in writing.
Decision
Decision and handover
The pilot ends with a memo that assesses the result against the criteria written down at the start.
- Aurora AI
- Writes the memo with a go or no-go recommendation and hands over the configuration documentation.
- Your team
- The accountable person makes the decision, and the team takes over the configuration and keeps maintaining it as code.
- We check
- The decision is in writing and justified against the criteria. The configuration stays in the repo whatever the outcome.
What stays in your repo
The configuration is built in your repo and reviewed by your team. You keep it after a no-go decision too.
.github/copilot-instructions.md
Repository-wide instructions
Shared working rules for the project: conventions, builds and tests. Instructions guide the agent, but they do not enforce rules. Hooks and the PR gate do that.
.github/instructions/
Path-specific instructions
*.instructions.md files with rules for particular parts of the code, such as tests or database migrations.
AGENTS.md
Agent instructions
Rules for agents, which the cloud agent reads together with the other instruction files.
.github/agents/
Agent profiles
Agents for recurring roles. Each has its own instructions and can be limited to a set list of tools. They work in the cloud agent, in Copilot CLI and in supported IDEs.
.github/skills/
Team skills
Your team’s written procedures, stored in the repo as project skills.
.github/hooks/
Hooks
Your own commands that run at defined points in the agent’s work. A hook that runs before a tool call can allow or block it. They work in Copilot CLI and in the cloud agent.
.github/workflows/copilot-setup-steps.yml
Cloud agent environment
A GitHub Actions workflow that sets up tools and dependencies before the cloud agent starts work.
MCP and network access
Cloud agent settings
MCP servers with a list of allowed tools, and a firewall that limits the agent’s internet access. These are repository settings on GitHub, not a file.
organisation policies
Organisation policies
Admin settings: which features, agents and models are available, which MCP servers may be connected, which files Copilot should ignore, and which budgets apply.
.github/CODEOWNERS
PR gate
Owners for the agent configuration, plus branch rules with required checks. A change to instructions, hooks or the agent environment waits for review by the named person.
go/no-go memo
Decision memo
A written assessment of the pilot against the criteria agreed before kickoff, with a go or no-go recommendation.
team
A trained team
Developers who know the configuration, change it through PRs and can maintain it on their own.
Your admins put organisation policies, branch rules and the MCP and network settings in place in GitHub’s settings, outside the repo files. The memo goes to the person who makes the decision, and the know-how stays with your team.
Our own example
We work the same way ourselves
The site you are reading is developed by AI agents under the same rules we put in place in the pilot. Our repo is on GitHub too.
- Agents have defined roles, such as planning, copy, site building, SEO and QA.
- Every agent works through a PR, and automatic gates check every change.
- Changes to agent definitions, scripts and gates wait for a person to review them and merge them by hand.
We have already delivered a GitHub Copilot rollout for a client. As with all our client work, we do not name the company.
# Scope: any open PR targeting main whose checks are green (operator's
# explicit choice), EXCEPT a PR that changes code or gates: `scripts/**`,
# `.github/**` (incl. pr-guards.yml), `.claude/**`, `package.json`,
# `package-lock.json` (any folder). […]
# […] Gated PRs get the label `needs-adam` and a comment, and wait for
# Adam to merge by hand […]An excerpt from the auto-merge rule in our repo
A PR that changes agent definitions, scripts or gates is not merged automatically. It waits for the founder to merge it by hand. This rule comes from a security decision: content that an outsider feeds to an agent must not be able to change code or gates and have that change go live on its own.
After the decision
The pilot does not turn into a wider rollout on its own. You decide the next step, based on the memo.
A go decision
The next step is a rollout to more teams and repos. We agree its scope, time and cost separately, based on the pilot’s findings.
A no-go decision
You keep the configuration in the repo and the memo. You know why it is not worth going further right now.
When a GitHub Copilot pilot makes sense
The pilot helps when
- Your company has GitHub Copilot licences, but the team mostly uses autocomplete.
- Each developer switches on the agents in their own way, some of them on personal plans.
- Someone on your side can make the go/no-go decision and own it.
- Your security team is asking what the agent may do in your code and needs the answers in writing.
The pilot is not the right choice when
- You are still choosing a tool. Then start with a conversation about how your team works.
- Nobody on your side can take responsibility for the decision.
- You expect us to supply the licences. We do not sell them: you buy them directly from GitHub, on a Copilot Business or Enterprise plan.
- You want agent-made changes to reach your code without review.
Common questions
Is Aurora AI a GitHub partner or a Microsoft partner?
No. Aurora AI is an independent consultancy. We do not sell licences and we are not a billing intermediary. You buy licences directly from GitHub, on a Copilot Business or Enterprise plan, or under an agreement your company already has with Microsoft.
Will our code be used to train models?
According to GitHub’s documentation (as of October 2026), customer data from the Copilot Business and Enterprise plans is not used to train AI models. Individual plans are different: interaction data may be used for training unless the user opts out. So in the pilot we check who works on a personal plan, recommend moving to your organisation’s plan, and confirm these terms with your security team.
How long does the pilot take, and what does it cost?
That depends on the team, the repo and the decision criteria, so we do not publish prices on the site. We agree time and cost in writing before kickoff, after a first conversation. The tool itself is a separate cost: according to GitHub’s documentation, agent usage on the Business and Enterprise plans is billed by consumption, so in the pilot we set budgets with your admins. Our blog covers this in the article on GitHub Copilot’s move to usage-based billing.
GitHub Copilot changes often. What happens to the configuration?
The configuration lives in your repo and changes through a PR, like any other code. When the tool gets a new feature or changes its behaviour, the team updates the configuration in a normal PR. In the pilot, the team practises exactly this way of working.
What if the decision is no-go?
You keep the configuration and the memo. The memo shows which criteria were not met, so you know what would have to change before you revisit the decision.
Can you roll out GitHub Copilot across the whole company?
That is a possible next step after a go decision. We plan and price that stage separately, once we know what the pilot showed.
More in the knowledge base
Articles and guides that go deeper into the topics of the pilot. If you are still choosing a tool, start with the comparison of coding agents.
Describe how your team uses GitHub Copilot today
Tell us which features your developers use today and on which plans, which repo you want to start in and who will make the go/no-go decision. We reply by email and suggest a conversation about the pilot.
The contact page leads to email. You do not need a finished specification.
Aurora AI is an independent consultancy. We are not a GitHub or Microsoft partner, we do not sell licences, and we are not a billing intermediary. GitHub Copilot is a GitHub product.