Rollout checklist

The sponsor clears blockers and funds time. The lead runs the program day to day.

Check that pilot users have seats, and review policies for Copilot cloud agent, automations and storing local sessions in the cloud.

Choose active repositories with good tests and owners who want to participate.

Include project instructions, a Setup script on session.create and a Run script with a server_ready_pattern.

Include engineers, PMs, designers and at least one business team so you test more than coding workflows. Their job is to find blockers in two weeks, not to prove value over a quarter.

Record PR cycle time, review turnaround and time to first commit before anyone starts.

Everyone installs, signs in and completes one Plan mode session on a real issue during the meeting.

Give pilot users one place to ask questions and share wins and problems.

Choose when to use local sandboxing or cloud sandboxes, and document the default in project settings.

Walk admins and security through settings, controls and sandbox guidance before users install anything.

Plan the validation cohort for weeks 1 and 2 and everyone with a seat by week 4. Decide who gets early builds and who stays on stable, which features to hold back, and any version pinning needs.

Decide who approves connectors and MCP servers, such as Sentry or WorkIQ, and confirm admin prerequisites for Microsoft 365 sources before pilot users ask.

Champions run local demos in launch week, answer first-line questions and report patterns back to the CoE.

Share proven prompts with Open in Copilot app links so teammates start from a working example.

Add .github/copilot-instructions.md and two or three skills that capture conventions, test commands and things the agent should never do.

Treat changes to .github/github-app.yml like CI changes. Scripts run with GitHub credentials.

Good first candidates are issue triage, a PR briefing and a weekly status draft.

Cloud automations should select only the tools a task needs. Write down who approves broader access.

Short write-ups with before and after numbers do more for adoption than any slide deck.

Many people with a Copilot seat have never heard of the app. Send the launch email and chat post, and put "try this" prompts where people already work.

Give each new user concrete prompts they can run on day one, including one for each canvas type.

Turn it on for everyone with a seat in one step on launch day. Watch support load for the first 48 hours and hold back only features that failed validation.

Bundle your approved agents, skills and MCP servers as a plugin in a CoE-owned private repository.

Register your marketplace with extraKnownMarketplaces, require the starter kit with enabledPlugins, and set allowedMcpServers or deniedMcpServers. Use MDM or a managed settings file where a rule must hold offline.

Ask users to report crashes and hangs in the feedback channel, and review them in office hours.

New hires install the app and complete the first-hour quickstart in their first week.

Deep links in runbooks and issue templates take people straight to the right session or automation.

Track which active repositories have a reviewed .github/github-app.yml and close the gap.

Hold separate sessions for engineers, PMs and designers using the use cases on this site.

Document when to pick a cloud sandbox, such as large upgrades or several parallel builds.

Once your catalog covers common requests, consider strictKnownMarketplaces so users install plugins only from approved sources. Review new plugin requests monthly.

Sponsor, lead and champions review metrics, top blockers and next month's focus.

Measure download, first open, first session and weekly active use. Fix the biggest drop first.

Help people pick between the app, the CLI, VS Code, automations and agents by the problem they have.

Show real internal workflows end to end and answer governance questions in the room.

Report changes in PR cycle time, review turnaround and throughput each quarter.

Retire automations nobody reads, and tighten prompts on the ones that produce noise.

Revisit this checklist and record which phase each team is in.

Collect the top requests from your feedback channel and share them with your GitHub account team.

Bring in new champions twice a year and update the prompt library as the app changes.