Weekly GitHub Copilot Roundup: Agents, Skills, and Governance

by TechHub

This week's Copilot updates were less about new chat features and more about making Copilot usable in operational workflows: agents that work in PRs and terminals, stronger admin controls (including data location), and portable “skills” and tool catalogs that keep behavior consistent. This continues last week's thread: as Copilot expands from IDE chat and autocomplete into PR and branch agents, CLI orchestration, and MCP tooling, GitHub is filling in the gaps around control, traceability, and rollout management.

Copilot agents move deeper into PRs and github.com workflows

After last week's work to make cloud-agent workflows faster and easier (parallel validations, Dependabot-to-agent remediation, and Mobile flows), GitHub is shifting more agent work onto github.com. A new “Fix with Copilot” button resolves PR merge conflicts using the Copilot cloud agent: click the button, post a prefilled PR comment, and the agent resolves conflicts, runs builds and tests, and pushes updates back to the PR. The goal matches last week's “shorter path to merge-ready” idea: fewer local context switches, while normal commits and repo validations still apply. The cloud-agent path also expands through @copilot mentions in PR conversations for common maintenance tasks such as fixing failing GitHub Actions tests, addressing review comments, or adding unit tests for edge cases. This carries last week's “agent-in-the-workflow” approach beyond security remediation into everyday PR work, while keeping changes inside the standard PR audit trail. Admin control remains a core requirement: Copilot cloud agent is available on paid plans, but Copilot Business/Enterprise admins must enable cloud agent before developers can use these PR commands and buttons. GitHub also added per-run model selection for the third-party Claude and Codex agents on github.com, so you choose the model at kickoff instead of relying on a single default. This matches last week's theme of making choices explicit (permission modes, thinking effort, BYOK/provider controls): per-run selection makes it clearer what you ran and why outputs differ. Enterprise enablement remains policy-driven: admins must enable Anthropic Claude and/or OpenAI Codex policies, and repo owners must enable the agent under Settings → Copilot → Cloud agent.

Governance and compliance: data residency, FedRAMP routing, and controlled rollouts

This week's governance updates continue last week's pattern of controls catching up with autonomy (stronger VS Code agent permissions, offline/BYOK in CLI, more reporting). Copilot now supports data residency for US and EU regions, plus routing through FedRAMP Moderate-authorized model hosts and infrastructure for US government compliance. GitHub says all GA Copilot capabilities are included (Agent mode, inline suggestions, Copilot Chat, cloud agent, Code Review, PR summaries, Copilot CLI), and requests route to compliant endpoints in the selected geography. In other words, the “where does it go?” control is aligning with the “what can it do?” controls across IDE, CLI, and github.com. Supported models span OpenAI and Anthropic (including GPT-5.4, Claude Sonnet 4.6, Claude Opus 4.6) with a model-by-region matrix. Teams should expect constraints, especially if they used last week's model configurability: Gemini isn't supported (there are no suitable data-resident inference endpoints in this setup), and new models may show up later in resident regions. There is also a cost change: data residency/FedRAMP requests apply a 10% increase to the model multiplier for premium request accounting, which ties back to last week's budgeting and limits planning (quotas, deprecations, plan standardization). For customers on Data Resident GitHub Enterprise Cloud (ghe.com / “Proxima”), the practical next step is enabling enforcement policies like “Restrict Copilot to Data Residency Models” so inference and Copilot data stay in-region. Plan for previews and newly released features to land later in data-residency tenants, so enablement guidance may need to differ between standard Enterprise Cloud and ghe.com. That mirrors last week's split between “the feature exists” and “the feature is manageable at org scale.”

The “skills” ecosystem grows up: Custom Skills, gh skill, and enterprise plugin catalogs

Copilot customization is moving from one-off prompting to versioned, shareable runbooks, which matches last week's IDE and CLI direction around instruction management, better agent hooks, and more repeatable sessions with artifacts. GitHub Copilot Custom Skills are the runbook unit for Agent mode, typically a folder under .github/skills/<name>/ with required SKILL.md plus optional scripts, templates, and resources. The guidance is specific: Copilot first reads only the skill's name + description (~100 tokens) to decide whether to load it, so descriptions should lead with trigger keywords and phrasing, and the skill should load referenced files only when needed. The “deployment-health” example encodes a real check: a Python script reads endpoints, measures latency and thresholds, generates an HTML report, and Copilot runs it and summarizes results. That aligns with last week's focus on inspectable, repo-resident artifacts. Managing skills is the next step, and GitHub addresses it with gh skill in GitHub CLI v2.90.0+ (public preview). It reads like last week's governance follow-through, but applied to the customization supply chain: install, update, and publish workflows with provenance controls. You can pin installs to a git tag or commit SHA, detect upstream changes via git tree SHA, and store provenance in SKILL.md frontmatter so the origin remains even if copied. For authors, gh skill publish validates against the agentskills.io spec and pushes security practices (tag protection, secret scanning, code scanning), with optional immutable releases tied to tags. GitHub also calls out the risk model: skills can contain malicious scripts or prompt injection, so gh skill preview is recommended before installing. This matches last week's safety framing (sandboxing MCP servers, safer execution, better debugging). Separately, Azure introduced an Azure API Center plugin marketplace endpoint (public preview) to help platform teams distribute approved tool extensions. This connects directly to last week's MCP operationalization theme: API Center provisions a Git-based marketplace.git endpoint that tools can consume. The post names Claude Code and GitHub Copilot CLI as consumers: developers add the URL and browse or install plugins from a governed, authenticated source instead of relying on internal docs. The practical result is that skills, MCP servers, and plugins can behave more like managed internal packages with central inventory and consistent installs. That matches what we're also seeing with PR cloud agents and the CLI as a formal runtime.

Copilot CLI: auto model routing, remote-controlled sessions, and “plan → implement” workflows

This week's CLI changes extend last week's arc: from “Copilot in the terminal” to a configurable agent runtime (BYOK/local models, offline mode, MCP tools, plugins) with clearer controls. First, auto model selection is now GA in Copilot CLI across all plans: set the model to “auto” and each request routes to an appropriate model (currently including GPT-5.4, GPT-5.3-Codex, Sonnet 4.6, Haiku 4.5) to improve availability and reduce rate limits. The CLI shows which model handled each request, continuing last week's theme that traceability matters. Billing follows the chosen model multiplier; auto is limited to 0x-1x models and includes a 10% multiplier discount for paid subscribers (for example, 1x billed as 0.9 under auto), which ties back to last week's cost and ops planning. Second, GitHub is previewing remote control for Copilot CLI sessions via copilot --remote. The session streams to GitHub and provides a link or QR code to view or control from the web or GitHub Mobile (with prerelease mobile builds). This continues last week's “Copilot in more places” direction by turning a long-running CLI session into a shared artifact, rather than a separate mobile or web copilot. You can send steering messages (including queued “keep going”), review and edit the plan before execution, switch modes (plan/interactive/autopilot), stop the session, and approve or deny permission prompts, while still respecting existing CLI permissions and Business/Enterprise policies. It is the same “more autonomy with explicit approvals and governance hooks” idea, applied to where supervision happens. Hands-on build stories show how the modes fit together. One uses plan mode to generate plan.md, then switches models (for example, Sonnet for planning and Claude Opus 4.7 for implementation) to build a Node.js terminal UI “emoji list generator” using @github/copilot-sdk, @opentui/core, and clipboardy. That kind of model switching matches last week's cross-model review idea: planning, implementation, and review as separate phases with checkpoints. Another example (a personal “command center” desktop app) shows a split between supervised changes in VS Code interactive agent mode and background work delegated to Copilot Cloud Agent, along with the practical reminder that agents often add code faster than they remove it, so cleanup still benefits from human refactoring. A short onboarding demo shows Copilot CLI generating a plain-English repo overview from the terminal instead of manual file browsing.

Models and IDE integrations: Opus 4.7 rollout, Visual Studio changes, and Azure MCP built-in

Model availability and IDE ergonomics shifted this week, connecting to last week's themes around model churn, explicit settings, and MCP parity across surfaces. GitHub Copilot is rolling out Claude Opus 4.7 as a GA model across IDEs, CLI, github.com, GitHub Mobile, and Copilot Coding Agent. The picker is also being simplified: Opus 4.7 will replace Opus 4.5 and 4.6 in the Pro+ model picker over the coming weeks, which reinforces last week's reminder to document intent (speed/cost/reasoning) rather than hard-coding versions. On cost, Opus 4.7 launches with a 7.5x premium request multiplier under promo pricing through April 30, and Business/Enterprise still require admins to enable the Opus 4.7 policy. That means more model choice, but still behind org policy. In Visual Studio, two Copilot-adjacent changes stood out. Visual Studio 2022 now ships Azure MCP tools built in (via the “Azure development” workload) starting with VS 17.14.30+, so you no longer need a separate “Copilot for Azure” extension. This follows last week's trajectory where MCP becomes part of the default IDE surface rather than an add-on. Once enabled in Copilot Chat's tool picker, the Azure MCP Server exposes 230+ tools across 45 Azure services for tasks like listing resources, deploying via azd to App Service, running AppLens and health checks, and generating and running KQL queries in Log Analytics. Updates now follow the Visual Studio Installer cadence, but tools are off by default and gated by Azure permissions plus sign-in to GitHub and Azure. That matches last week's framing around explicitly allowed surfaces. Visual Studio 2026 18.5 changes completion behavior by prioritizing IntelliSense list completions so Copilot inline suggestions do not compete for the same accept gesture. It also adds a Copilot-driven debugger agent workflow: from an issue link or prompt, Copilot forms hypotheses, sets conditional breakpoints, runs under the debugger, and proposes fixes based on what it observes. This matches last week's theme of richer debugging and more autonomy, but with a loop driven by runtime state rather than only static edits. Coverage also notes ongoing friction (reduced theme token granularity impacting readability, more forceful update prompts), which matters because Copilot usage depends on IDE stability.

Other GitHub Copilot News

Security and compliance are showing up more often in day-to-day agent adoption guidance, not only as admin settings. This matches last week's shift toward governance that you can measure (usage metrics, security entry points, constrained capabilities with audit trails). A DevOps playbook argues that agents amplify existing engineering discipline, recommends treating repos as explicit agent interfaces (via .github/copilot-instructions.md and spec and constraint files), and using CI/CD as an active verifier with structural, semantic, and provenance checks plus defenses against prompt injection and supply-chain abuse.