DEV Community: Marcel.L

Mastering Code Reviews with GitHub Copilot: The Definitive Guide

Marcel.L — Fri, 13 Mar 2026 09:46:56 +0000

Mastering Code Reviews with GitHub Copilot: The Definitive Guide

Pull requests keep piling up. Your team reviews dozens a week, and each one needs careful attention to security, performance, style, and correctness. Human reviewers catch domain-specific issues that machines miss, but they also miss the mechanical things that machines are brilliant at, such as spotting unhandled edge cases, flagging deprecated API calls, or enforcing naming conventions across hundreds of files.

What if you could get an AI-powered first pass on every pull request before a human even looks at it? Better still, what if that AI reviewer lived in your editor, your terminal, your GitHub.com workflow, and your custom automation, all at once?

GitHub Copilot offers not one but eight distinct surfaces for AI-assisted code review. This guide maps every one of them, shows you how to configure each for maximum value, and walks through a real end-to-end review workflow that combines several surfaces together.

If you have been following the GitHub Copilot series, you have already seen individual pieces of this puzzle across previous posts on custom instructions, MCP, the coding agent, and the customisation guide. This post brings everything together through the lens of code review.

The 8 Surfaces of AI-Assisted Code Review

Before we dive into each method, here is the landscape at a glance. Every surface serves a different context in your workflow.

#	Method	Where It Runs	Best For	Setup Required	Automation Level
1	GitHub.com Native Review	Browser (github.com)	PR reviews at scale	Org/repo settings	High
2	VS Code Review Selection	Editor (VS Code)	In-flight code review	Settings toggle	Low
3	Custom Instructions	VS Code + GitHub.com	Team review standards	`.github/` config files	Medium
4	Prompt Files	VS Code	Repeatable review workflows	`.prompt.md` files	Medium
5	Custom Agents	VS Code	Specialised review roles	`.agent.md` files	Medium
6	MCP-Powered PR Review	VS Code	Deep PR analysis with live context	MCP server config	Medium
7	Coding Agent	GitHub Actions	Fully automated review tasks	Coding agent enabled	High
8	Copilot CLI	Terminal	Pre-commit local checks	Copilot CLI installed	Low

The rest of this guide walks through each surface in detail, then ties them together in a worked example.

1. GitHub.com Native Copilot Code Review

This is the highest-leverage surface for teams. Copilot acts as an automated reviewer directly on your pull requests in the browser, no editor or CLI needed.

How It Works

Navigate to any pull request on github.com.
Click Reviewers in the sidebar and select Copilot from the reviewer list.
Copilot analyses the diff and posts inline review comments, just like a human reviewer would.

You can also configure Copilot to automatically review every PR when it is opened or updated, so you never have to remember to request it.

What Feedback Looks Like

Copilot's review comments appear inline on the PR diff. Each comment includes:

A description of the issue found.
A suggested fix (where applicable) that you can accept with one click.
Severity context so you can prioritise critical issues over style nits.

Comments cover categories such as:

Bugs and logic errors (off-by-one, null dereferences, race conditions).
Security concerns (injection risks, hardcoded secrets, missing input validation).
Performance issues (unnecessary allocations, N+1 queries, blocking calls in async code).
Best practice violations (deprecated APIs, missing error handling, inconsistent patterns).

Custom Coding Guidelines

By default, Copilot reviews against general best practices. To tailor feedback to your team's standards, create a coding guidelines file:

.github/copilot-code-review-instructions.md

This file contains natural language descriptions of your team's review standards. For example:

## Security

- All database queries must use parameterised queries, never string concatenation.
- Secrets must be loaded from environment variables or a vault, never hardcoded.
- All public endpoints must validate and sanitise input.

## Naming

- Use PascalCase for public methods, camelCase for private methods.
- Infrastructure resources must follow the pattern: {env}-{region}-{service}-{resource}.

## Testing

- Every public method must have at least one unit test.
- Integration tests must clean up after themselves.

## Error Handling

- Never swallow exceptions silently. Log at minimum.
- Use typed errors rather than generic Error objects.

When Copilot reviews a PR in your repository, it reads these guidelines and incorporates them into its analysis. This is how you move from generic AI feedback to feedback that matches your team's actual standards.

Enabling at Organisation and Repository Level

Repository administrators can configure Copilot code review under Settings > Copilot > Code review:

Enable/disable Copilot as an available reviewer.
Auto-review: Automatically request Copilot review on every new or updated PR.
Custom coding guidelines: Point to your .github/copilot-code-review-instructions.md file.

At the organisation level, administrators can enable or enforce code review settings across all repositories, ensuring consistent review coverage.

Limitations

Language support: Copilot code review works best with widely-used languages (JavaScript, TypeScript, Python, Go, Java, C#, Ruby, etc.). Less common languages may receive less detailed feedback.
Context window: Very large PRs may exceed the context window. Copilot reviews what it can and notes when it could not review all files.
Not a replacement for human review: Copilot catches mechanical issues brilliantly but does not understand your business domain. It is a first pass, not the final word.

Tip: You can work around the language support limitation by pairing Copilot with an advanced reasoning model (such as Claude Opus or Gemini 3 Pro in extended thinking mode) or a custom agent that has access to online sources via MCP web tooling or Playwright. For example, create a .agent.md reviewer that uses a web search tool to look up the latest best practices, idioms, or security advisories for a less common language. The agent can research real time strategies, verify its findings against up to date documentation, and cite the references it used so you can check them yourself. This is especially useful for newer frameworks or niche languages where the model's training data may be limited. See Section 5: Custom Agents and Section 6: MCP-Powered PR Review later in this guide for setup details.

Official docs: GitHub Copilot code review

2. VS Code Review Selection

If GitHub.com native review is the "PR-level" surface, VS Code review selection is the "code-level" surface. It lets you review any block of code in the editor, at any time, not just when a PR is open.

How to Trigger It

Select code in the editor (a function, a class, a block, whatever you want reviewed).
Right-click and choose Copilot > Review and Comment.
Alternatively, open the Command Palette (Ctrl+Shift+P) and run GitHub Copilot: Review and Comment.

Copilot analyses the selected code and posts its findings directly as editor comments, inline in your code.

You can also trigger a review of all uncommitted changes directly from the Source Control panel.

Copilot posts its findings as inline comments with suggested changes that you can apply or discard with a single click.

Configuring Review Instructions

You can customise what Copilot looks for during VS Code reviews using two settings. These live in your VS Code settings.json file. To open it:

Press Ctrl+Shift+P (or Cmd+Shift+P on macOS) and run Preferences: Open Settings (JSON).
For workspace-level settings shared with your team, create .vscode/settings.json in your repository root.

Add or update the following:

{
  // Enable the review selection feature
  "github.copilot.chat.reviewSelection.enabled": true,

  // Define what Copilot should focus on during reviews
  "github.copilot.chat.reviewSelection.instructions": [
    {
      "text": "Check for security vulnerabilities including injection attacks, hardcoded secrets, and missing input validation.",
    },
    {
      "text": "Flag any functions longer than 50 lines and suggest decomposition.",
    },
    {
      "text": "Verify error handling covers all failure paths.",
    },
  ],
}

You can also point to an external file for review instructions:

{
  "github.copilot.chat.reviewSelection.instructions": [
    {
      "file": ".github/review-instructions.md",
    },
  ],
}

This keeps your review criteria version-controlled and consistent across the team.

When to Use This Surface

During development: Review your own code before you even commit.
Pair programming: Get an instant second opinion on a tricky function.
Learning: Understand unfamiliar code by asking Copilot to review and explain it.
Pre-PR polish: Catch issues before they reach the formal review stage.

For a deeper dive into VS Code Copilot settings, see my earlier post: Tune GitHub Copilot Settings in VS Code

3. Custom Instructions for Code Reviews

Custom instructions shape how Copilot behaves across your workspace. For code review, they let you embed your team's review standards so that every interaction, whether in chat, inline completion, or review, reflects your agreed-upon practices.

Where to Define Review Instructions

You have three options, each with a different scope:

File	Scope	Use When
`.github/copilot-instructions.md`	Every Copilot interaction	You want review standards applied everywhere
`.github/instructions/code-review.instructions.md`	Pattern-matched files	You want review rules for specific file types
`AGENTS.md`	Multi-agent workflows	You use multiple AI tools, not just Copilot

Example: A Code Review Instructions File

Create .github/instructions/code-review.instructions.md:

---
applyTo: '**/*.{ts,js,py,go,cs}'
---

# Code Review Standards

When reviewing code, always check:

## Security

- No hardcoded secrets, tokens, or connection strings.
- All user input is validated and sanitised before use.
- SQL queries use parameterised statements.
- No sensitive data logged at INFO level or above.

## Reliability

- All async operations have proper error handling.
- Network calls include timeouts and retry logic.
- Resource cleanup is handled in finally blocks or using statements.

## Maintainability

- Functions do one thing and are under 40 lines where practical.
- Variable names are descriptive and follow project conventions.
- No commented-out code left in place. Use version control instead.

## Performance

- No unnecessary allocations in hot paths.
- Database queries are indexed and avoid N+1 patterns.
- Large collections use streaming or pagination rather than loading everything into memory.

The applyTo glob ensures these instructions activate whenever Copilot works with source code files, without cluttering interactions with documentation or configuration files.

How Instructions Shape Review Output

When you use Copilot to review code, either via VS Code review selection, chat, or GitHub.com, it reads these instructions and adjusts its analysis accordingly. The instructions act as a persistent checklist that Copilot applies without you having to repeat it every time.

This is the foundation layer. The other surfaces (prompt files, agents, MCP) build on top of it.

For a full walkthrough, see: Instructions and Prompt Files to supercharge VS Code with GitHub Copilot

4. Prompt Files for Structured Reviews

While instructions define standards, prompt files create repeatable review workflows that you invoke on demand. Think of them as named review commands.

Creating a Review Prompt File

Create .github/prompts/security-review.prompt.md:

---
description: 'Run a security-focused code review on the selected code'
mode: 'ask'
tools: ['githubRepo', 'codebase']
---

Perform a thorough security review of the current code. For each issue found, provide:

1. **Severity**: Critical / High / Medium / Low
2. **Location**: File and line reference
3. **Issue**: What the problem is
4. **Risk**: What could go wrong if left unfixed
5. **Fix**: Specific code change to resolve it

Check for:

- Injection vulnerabilities (SQL, XSS, command injection)
- Authentication and authorisation gaps
- Hardcoded secrets or credentials
- Missing input validation
- Insecure cryptographic usage
- Sensitive data exposure in logs or error messages
- Missing rate limiting on public endpoints

Format output as a table sorted by severity.

Using It

In VS Code chat, type /security-review and Copilot runs the review following your exact template. The output is structured, consistent, and actionable every time.

More Review Prompt Ideas

Here are additional prompt files you might create:

Prompt File	Purpose
`performance-review.prompt.md`	Analyse code for performance bottlenecks, memory leaks, and scaling concerns
`test-coverage-review.prompt.md`	Identify untested code paths and suggest test cases
`accessibility-review.prompt.md`	Check UI code for accessibility compliance (WCAG)
`iac-review.prompt.md`	Review Terraform/Bicep for security, cost, and best practices
`api-review.prompt.md`	Review API endpoints for consistency, versioning, and documentation

Each prompt file becomes a slash command in VS Code chat. Your team builds a library of review plays that anyone can run.

For more on prompt files, see: GitHub Copilot Instructions vs Prompts vs Custom Agents vs Skills vs X vs WHY?

5. Custom Agents for Code Reviews

Custom agents take things further by creating a dedicated reviewer persona with specific tool access and boundaries. Instead of a general-purpose assistant that also reviews code, you build a specialist.

Why Use a Custom Agent for Reviews?

Role clarity: The agent only reviews. It does not generate new code, refactor, or make changes.
Tool restrictions: You can limit the agent to read-only tools so it cannot accidentally modify files during review.
Consistent voice: The agent's system prompt defines its review personality, checklist, and output format.
Team alignment: Everyone uses the same reviewer agent, so feedback is consistent regardless of who runs it.

Example: Security Review Agent

Create .github/agents/security-reviewer.agent.md:

---
description: 'A security-focused code reviewer that analyses code for vulnerabilities and compliance issues'
tools: ['codebase', 'fetch', 'githubRepo']
---

You are a senior security engineer performing code review. Your role is strictly read-only. You analyse code but never modify it.

## Review Process

1. Examine the code provided or referenced in the conversation.
2. Check against the OWASP Top 10, CWE Top 25, and project-specific security policies.
3. For each finding, provide severity, location, description, risk, and remediation guidance.

## Output Format

Present findings in a structured report:

### Summary

- Total issues found: X
- Critical: X | High: X | Medium: X | Low: X

### Findings

For each finding:

- **ID**: SEC-001
- **Severity**: Critical/High/Medium/Low
- **Category**: (e.g., Injection, Auth, Crypto)
- **Location**: File and line
- **Description**: What the issue is
- **Risk**: Impact if exploited
- **Remediation**: How to fix it

## Rules

- Never suggest "it looks fine" without evidence of thorough checking.
- Always check for hardcoded secrets, even in test files.
- Flag any use of deprecated cryptographic algorithms.
- If you cannot determine security posture from the available context, say so explicitly.

Using It

Switch to the security-reviewer agent in VS Code chat. Everything you ask is filtered through the security reviewer's lens. Ask it to review a file, a diff, or a PR, and you get structured security feedback every time.

You can create different review agents for different concerns: architecture-reviewer.agent.md, performance-reviewer.agent.md, accessibility-reviewer.agent.md, each with its own checklist and tool set.

For a deeper look at custom agents: GitHub Copilot Instructions vs Prompts vs Custom Agents vs Skills vs X vs WHY?

6. MCP-Powered PR Reviews

The Model Context Protocol (MCP) lets Copilot connect to external tools and data sources. For code review, the GitHub MCP server is the key enabler. It gives Copilot live access to pull request data: diffs, comments, linked issues, CI status, and more.

Setting Up the GitHub MCP Server

If you followed my earlier post on MCP setup, you already have this configured. The GitHub MCP server provides tools such as:

get_pull_request to fetch PR metadata and description.
get_pull_request_diff to retrieve the actual code changes.
list_pull_request_comments to see existing review feedback.
get_issue to pull in linked issue context.
list_pull_request_files to see which files changed.
create_pull_request_review_comment to post review comments back.

Review Workflow with MCP

Here is how you can run a PR review entirely from VS Code chat using MCP:

Step 1: Fetch the PR context

Look at PR #42 in my repository. Fetch the diff, the PR description, and any linked issues.

Copilot uses the MCP tools to pull all the context it needs.

Step 2: Analyse the changes

Review the changes in PR #42 for security issues, bug risks, and adherence to our coding standards.
Cross-reference with the linked issue to ensure all requirements are addressed.

Step 3: Post feedback

Post your review findings as inline comments on PR #42, grouped by severity.

Copilot can post review comments directly on the PR via MCP, so the feedback appears on github.com where the rest of the team can see it.

Why MCP Changes the Game

Without MCP, Copilot in VS Code only sees the files open in your editor. With MCP, it can:

Pull in the full PR diff, even files you have not opened.
Read existing review comments so it does not duplicate feedback.
Check CI status to correlate test failures with code changes.
Follow linked issues to understand the intent behind the changes.
Post comments back to the PR so everything stays in one place.

This turns VS Code chat into a full PR review workstation.

For MCP setup details, see: Supercharge VSCode GitHub Copilot using MCP

7. Coding Agent for Automated Reviews

The GitHub Copilot coding agent is an autonomous AI that runs in a GitHub Actions environment. While it is primarily designed for coding tasks, you can use it for review-adjacent automation.

How It Applies to Code Review

The coding agent works through GitHub Issues. You describe a task, assign it to Copilot, and it opens a PR with the result. For review workflows, consider these patterns:

Pattern 1: Fix issues found in review

Title: Address review feedback on PR #42

Review the comments on PR #42 and implement the requested changes:
- Fix the SQL injection vulnerability in UserService.cs
- Add input validation to the CreateUser endpoint
- Add unit tests for the new validation logic

Assign this issue to Copilot, and it will create a new PR addressing the review feedback.

Pattern 2: Review-driven refactoring

Title: Refactor authentication module per review guidelines

The authentication module in src/auth/ has accumulated technical debt.
Apply our coding standards from .github/copilot-code-review-instructions.md:
- Extract duplicated validation logic into shared utilities
- Add proper error handling to all OAuth flows
- Ensure all endpoints validate JWT tokens consistently

Pattern 3: Pre-review preparation

Title: Add missing tests before review

Before PR #42 is reviewed, ensure:
- All new public methods have unit tests
- Integration tests cover the new API endpoints
- Test coverage for the changed files is above 80%

The coding agent handles the mechanical work so that human reviewers can focus on design decisions and domain logic.

Key Considerations

The coding agent cannot approve or merge PRs. It always produces a PR for human review.
Every PR it creates is scanned by CodeQL and secret scanning.
It runs in an isolated container, so it cannot affect your production environment.
One task, one PR. Complex reviews may need to be broken into separate issues.

For full setup and use cases, see: Using GitHub Copilot Coding Agent for DevOps Automation

8. Copilot CLI for Local Reviews

GitHub Copilot CLI is a standalone terminal agent that replaces the retired gh copilot extension. You invoke it with the copilot command. It can read files, run shell commands, and interact with GitHub, making it ideal for reviewing changes before you commit or push.

Quick Local Review

Start an interactive session and ask Copilot to review your staged changes:

copilot

Then type your review prompt:

Review my staged changes for bugs, security issues, and style problems

Or use the programmatic interface for a one-shot review:

copilot -p "Review my staged changes for bugs, security issues, and style problems" --allow-tool='shell(git)'

Targeted Reviews

Review a specific file:

copilot -p "Review src/auth/login.ts for security vulnerabilities" --allow-tool='shell(cat)'

Review changes between branches:

copilot -p "Review the changes between main and feature/auth-refactor, focusing on authentication security" --allow-tool='shell(git)'

Check the changes in a pull request directly from the terminal:

copilot -p "Check the changes made in PR #42. Report any serious errors you find" --allow-tool='shell(gh)'

When to Use CLI Reviews

Pre-commit check: Catch issues before they enter version control.
Quick sanity check: Get a fast opinion on a small change without opening an editor.
CI integration: Add a review step to your pipeline that flags issues early.
Remote work: Review code on a server where you only have terminal access.

The CLI is a full agentic experience. It can read your codebase, run shell commands, and even create pull requests. For review purposes, use --allow-tool='shell(git)' to give it read access to your Git history without granting broader permissions.

For CLI setup and more examples, see: GitHub Copilot CLI: A DevOps Engineer's Practical Guide

The Comparison Cheat Sheet

Use this table to pick the right review surface for your situation:

Method	Where	Best For	Setup Effort	Automation	Team Visibility
GitHub.com Native	Browser	PR reviews at scale	Low (org setting)	High (auto-review)	High (comments on PR)
VS Code Selection	Editor	In-flight code	Minimal (built-in)	Manual trigger	Low (local only)
Custom Instructions	Both	Team standards	Low (one file)	Passive (always-on)	Medium (shared via repo)
Prompt Files	VS Code	Repeatable plays	Low (per prompt)	On-demand	Medium (shared via repo)
Custom Agents	VS Code	Specialised roles	Medium (agent config)	On-demand	Medium (shared via repo)
MCP PR Review	VS Code	Deep PR analysis	Medium (server setup)	On-demand	High (can post to PR)
Coding Agent	GitHub	Automated fixes	Low (already enabled)	High (issue-driven)	High (creates PRs)
Copilot CLI	Terminal	Pre-commit checks	Low (install `copilot`)	Manual/scriptable	Low (local only)

Choosing Your Starting Point

Team just getting started? Enable GitHub.com native review. It requires no editor changes and covers every PR automatically.
Individual developer wanting better habits? Start with VS Code review selection. It is built in and instant.
Team with established coding standards? Add custom instructions. Your standards become Copilot's standards.
Mature team wanting structured workflows? Build prompt files and agents. Create a library of review plays.
Dealing with complex PRs and cross-references? Set up MCP. Live context makes reviews dramatically better.

Worked Example: End-to-End PR Review

Let us walk through a realistic review workflow that combines multiple surfaces. Imagine you have a teammate's PR that adds a new user registration endpoint with database access and email notifications.

Step 1: Pre-Push Local Check (CLI)

Before the PR even exists, the developer reviews their own changes locally:

copilot -p "Review my staged changes for security issues, particularly around user input handling and database access" --allow-tool='shell(git)'

Copilot flags that the email field is not validated and the SQL query uses string interpolation. The developer fixes both before pushing.

Step 2: PR Created, Copilot Auto-Reviews (GitHub.com)

The developer pushes and creates a PR. Copilot automatically reviews it (auto-review is enabled) and posts inline comments:

High: Missing rate limiting on the registration endpoint.
Medium: The error response leaks internal database column names.
Low: Variable usr should be user per naming conventions.

The team's .github/copilot-code-review-instructions.md includes rate limiting and error handling standards, so Copilot catches these against the team's own rules.

Step 3: Deep Dive in VS Code (Review Selection + MCP)

You open the PR branch in VS Code. You select the registration handler function and use Copilot > Review and Comment for a focused analysis.

Then you use MCP to pull in broader context:

Fetch PR #87, including the diff, linked issue #156, and any existing review comments.
Review the entire PR for security compliance. Consider the requirements in issue #156
and check that all acceptance criteria are met.

Copilot correlates the PR changes with the issue requirements and identifies that one acceptance criterion (email verification flow) is missing from the implementation.

Step 4: Structured Security Review (Prompt File)

You run /security-review in VS Code chat. The prompt file produces a structured table:

Severity	Location	Issue	Fix
Critical	`register.ts:45`	No rate limiting	Add express-rate-limit middleware
High	`register.ts:62`	SQL string interpolation	Use parameterised query
Medium	`register.ts:78`	Error leaks DB schema	Return generic error message
Low	`email.ts:12`	SMTP credentials in env check	Add startup validation

Step 5: Automated Fix (Coding Agent)

For the mechanical fixes, you create a GitHub Issue:

Title: Address security review findings on PR #87

Fix the following issues found during code review:
1. Add rate limiting middleware to POST /api/register (max 5 requests per minute per IP)
2. Convert SQL query on line 62 to use parameterised statements
3. Replace detailed error responses with generic messages
4. Add SMTP credential validation at startup

The coding agent picks up the issue, implements the fixes, and opens a follow-up PR.

Step 6: Human Review

With the mechanical issues resolved, the human reviewer focuses on what matters most:

Does the registration flow make business sense?
Is the email notification content appropriate?
Does the database schema support future requirements?
Are the architectural decisions sound?

AI handled the mechanical first pass. The human focuses on design, domain, and judgement.

Tips and Best Practices

Layer your review surfaces. No single surface catches everything. Use GitHub.com auto-review as your always-on baseline, prompt files for structured deep dives, and MCP for complex PRs.
Write clear review instructions. Whether in .github/copilot-code-review-instructions.md, VS Code settings, or agent definitions, specific instructions produce specific feedback. "Check for security issues" is vague. "Ensure all user input is sanitised, all queries are parameterised, and no secrets are hardcoded" is actionable.
Treat AI review as a first pass, not the final word. Copilot is exceptional at catching mechanical issues (bugs, security patterns, style violations) but does not understand your business domain. Human reviewers should always have the last say on design, architecture, and domain logic.
Keep review instructions version-controlled. Store them in .github/ so they evolve with your codebase and are reviewed like any other code change.
Start small, expand gradually. Enable GitHub.com auto-review today. Add custom instructions next week. Build your first prompt file next month. You do not need all eight surfaces on day one.
Use different agents for different review concerns. A security review agent should not worry about variable naming. A style review agent should not flag architectural choices. Specialised agents give focused, high-quality feedback.
Combine MCP with prompt files for maximum context. A prompt file defines the review structure. MCP provides the live data (PR diff, comments, issues). Together, they produce the most thorough reviews.
Review the reviewer. Periodically check Copilot's review output against your team's actual standards. If it is flagging too many false positives or missing real issues, update your instructions.

Conclusion

Code review is one of the highest-value activities in software engineering, and also one of the most time-consuming. GitHub Copilot provides eight distinct surfaces for AI-assisted review, each suited to a different moment in your workflow:

GitHub.com catches issues at the PR level, automatically.
VS Code catches issues at the code level, on demand.
Custom instructions make your team's standards automatic.
Prompt files turn review workflows into repeatable commands.
Custom agents create dedicated reviewer personas.
MCP connects reviews to live PR data and project context.
The coding agent automates fixes for review findings.
The CLI enables fast local checks before code leaves your machine.

The real power comes from combining them. Start with GitHub.com auto-review as your baseline, layer on custom instructions for your team's standards, and add prompt files and agents as your review workflows mature.

Your reviewers will thank you. Your codebase will thank you. And the bugs that never make it to production? They will never know what hit them.

Author

Marcel.LFollow

Microsoft MVP in DevTech - DevOps | DevOps Architect | Technical speaker focused on Microsoft technologies, Agentic AI, IaC & automation in Azure. Find me on GitHub: https://github.com/Pwd9000-ML

Like, share, follow me on: 🐙 GitHub | 🐧 X | 👾 LinkedIn

Date: 13-03-2026

Evaluating LLM Models in GitHub Copilot. A Practical Scoring and Assessment Guide

Marcel.L — Fri, 06 Mar 2026 18:12:20 +0000

Evaluating LLM Models in GitHub Copilot. A Practical Scoring and Assessment Guide

GitHub Copilot gives us access to a fast-moving set of LLMs from multiple providers. That is great for innovation, but it also creates a practical problem for teams. Which model should you use for a specific task, and how do you justify that decision with evidence instead of gut feel?

This guide is a practical framework you can use with your own network and team. We will cover how model evaluation works, how to build your own scoring approach, and how to run repeatable comparisons so you can choose models with confidence as new releases arrive.

Why Model Evaluation Matters

Choosing a model is no longer a one-time decision.

Models are specialised: some are better for fast lightweight tasks, others for deeper reasoning and debugging.
Cost matters: different models have different premium request multipliers in Copilot.
Model catalogues change frequently: new models are added, and older ones are retired.
Teams need consistency: shared evaluation criteria helps avoid random model switching and uneven output quality.

If you do not evaluate, you usually optimise for what feels fastest in the moment. That often creates hidden costs later in rework, review cycles, and reliability issues.

Models Available in GitHub Copilot Today

GitHub maintains a live reference of supported AI models. The most important point is this. Treat the docs as the source of truth because availability can vary by client, plan, and release cycle.

Supported models: https://docs.github.com/en/copilot/reference/ai-models/supported-models
Model comparison: https://docs.github.com/en/copilot/reference/ai-models/model-comparison

At the time of writing, Copilot includes models from:

OpenAI (for example GPT family and Codex variants)
Anthropic (Claude family)
Google (Gemini family)
xAI (for example Grok Code Fast 1)
Copilot-tuned options in preview

A practical way to think about model choice:

Fast/simple tasks: quick syntax help, small edits, repetitive transformations
General coding/writing: day-to-day coding, docs, refactoring support
Deep reasoning/debugging: multi-step investigations, architecture-level decisions, complex defect analysis
Agentic workflows: long-running coding tasks in chat/agent modes

Also note:

Auto model selection is available in supported IDE chat experiences, and can choose a model automatically.
You can still override manually when you have evidence from your own evaluation.

How LLMs Are Evaluated in Industry

Public benchmark scores are useful signals, but they are not the whole story.

Common Benchmark Families

Benchmark	What it tests	Typical use
MMLU	Broad knowledge and reasoning	General model capability checks
HumanEval / MBPP	Code generation correctness	Coding assistant comparisons
SWE-bench	Real software issue resolution	Engineering task realism
GSM8K / MATH	Mathematical reasoning	Structured reasoning quality
ARC / HellaSwag	Commonsense and reasoning	General reasoning robustness
TruthfulQA	Truthfulness and hallucination tendency	Reliability risk checks
MT-Bench / Arena-style pairwise	Conversational quality and preference	Human preference alignment

Useful references:

MMLU paper: https://arxiv.org/abs/2009.03300
HumanEval repo: https://github.com/openai/human-eval
SWE-bench: https://www.swebench.com/
Chatbot Arena: https://lmarena.ai/
Hugging Face leaderboard: https://huggingface.co/spaces/open-llm-leaderboard/open_llm_leaderboard

Why Benchmarks Alone Are Not Enough

Benchmarks can miss your local context:

your coding standards
your cloud/platform stack
your repo structure
your incident patterns
your definition of acceptable risk

A model can rank highly and still underperform on your real workloads. That is why self-assessment is essential.

A Practical Evaluation Framework You Can Run Yourself

Use a lightweight internal framework you can rerun monthly or quarterly.

Step 1: Define Evaluation Scenarios

Create 10 to 20 prompts based on real work. Keep them representative and repeatable.

Examples for DevOps/platform teams:

Fix a failing GitHub Actions workflow from logs
Refactor a Terraform module and preserve backwards compatibility
Generate tests for a PowerShell script with edge cases
Write an incident summary from deployment telemetry

Step 2: Define a Scoring Rubric

Score each response against the same dimensions.

Dimension	1 (Poor)	3 (Acceptable)	5 (Excellent)
Correctness	Wrong or unusable output	Works with fixes	Works first time, production-ready
Reasoning quality	No clear logic	Basic explanation	Clear reasoning with trade-offs
Instruction adherence	Misses key constraints	Follows most constraints	Follows all constraints precisely
Security and safety	Introduces risky patterns	Neutral/safe enough	Proactively applies safer patterns
Maintainability	Hard to read/operate	Adequate quality	Clear, testable, maintainable output
Latency usefulness	Too slow for value	Acceptable speed	Fast with strong quality

Step 3: Run Blind Comparisons

Do not show model names to reviewers during scoring.

Use the same prompt set for each model.
Randomise response order.
Have at least two reviewers score each output.
Average the scores to reduce individual bias.

Step 4: Add Cost-Performance Scoring

Quality alone is not enough to pick a model. A model that scores slightly higher but costs several times more per request may not be worth it for everyday tasks. Adding a cost dimension keeps your evaluation grounded.

Where to find cost data. GitHub publishes premium request multipliers for each model in the Copilot docs. These multipliers tell you how many premium requests a single interaction with that model consumes relative to the baseline. Use this as your cost proxy.

Premium request costs: https://docs.github.com/en/copilot/managing-copilot/monitoring-usage-and-entitlements/about-premium-requests

Calculate a value score. Divide your average quality score by the model's premium multiplier:

Value Score = Average Quality Score / Premium Multiplier

Worked example. Suppose three models score as follows after your blind evaluation:

Model	Avg quality (1-5)	Premium multiplier	Value score
Model A	4.4	1x	4.4 / 1 = 4.4
Model B	4.7	3x	4.7 / 3 = 1.57
Model C	4.1	0.33x	4.1 / 0.33 = 12.42

Model B scores highest on raw quality, but its value score is the lowest because each request costs three times the baseline. Model C delivers almost the same quality at a fraction of the cost, making it the best value pick for lightweight tasks.

When to ignore the value score. Cost efficiency matters most for high-volume, routine tasks. For critical debugging or architecture decisions where correctness has outsized impact, pick the highest quality model regardless of cost. Use the value score as a guide, not a rule.

Practical Ways to Run Your Own Evaluation

There are several free approaches you can use depending on your team size and automation needs. Here are two that work well with GitHub Copilot.

Option A: Manual Side-by-Side Comparison in Copilot Chat

The simplest method is to use GitHub Copilot Chat directly. No extra tooling required.

Open Copilot Chat in VS Code and select your first model.
Run a prompt from your evaluation set and capture the response.
Switch to the next model using the model picker and run the same prompt.
Score each response using your rubric and record the results.

A simple markdown table works well for tracking:

| Prompt | Model A | Model B | Model C | Notes |
| --- | --- | --- | --- | --- |
| Fix failing workflow | 4 | 5 | 3 | B caught root cause immediately |
| Refactor Terraform | 3 | 4 | 4 | A missed a variable dependency |
| Generate Pester tests | 5 | 4 | 3 | A covered more edge cases |

This approach works best for:

Individual contributors evaluating models for their own workflow.
Small teams running a quick monthly check.
Getting started before investing in automation.

Tips for a fair manual comparison:

Use the exact same prompt text for each model.
Do not reveal the model name to the scorer if more than one person is reviewing.
Record latency (how long you waited) alongside quality scores.

Option B: Automated Evaluation with DeepEval

If you want repeatable, scriptable evaluation that integrates with CI/CD, DeepEval is a practical open-source choice. It uses pytest-style test cases and supports custom scoring criteria via an LLM-as-a-judge approach.

Website: https://deepeval.com/
GitHub: https://github.com/confident-ai/deepeval

1. Install

pip install -U deepeval

2. Create a test file

Create test_copilot_eval.py with test cases that match your evaluation scenarios:

import pytest
from deepeval import assert_test
from deepeval.metrics import GEval
from deepeval.test_case import LLMTestCase, LLMTestCaseParams


correctness = GEval(
    name="Correctness",
    criteria="The response must correctly identify the root cause and provide a secure, working fix.",
    evaluation_params=[
        LLMTestCaseParams.ACTUAL_OUTPUT,
        LLMTestCaseParams.EXPECTED_OUTPUT,
    ],
    threshold=0.5,
)

maintainability = GEval(
    name="Maintainability",
    criteria="The response must produce clear, readable, and well-structured code.",
    evaluation_params=[LLMTestCaseParams.ACTUAL_OUTPUT],
    threshold=0.5,
)


def test_workflow_fix():
    test_case = LLMTestCase(
        input="Given this GitHub Actions error: 'OIDC token audience invalid', identify root cause and fix.",
        actual_output="<paste model response here>",
        expected_output="The OIDC token audience must match the value configured in your identity provider. Update the audience field in your federated identity settings.",
    )
    assert_test(test_case, [correctness])


def test_terraform_refactor():
    test_case = LLMTestCase(
        input="Refactor this Terraform snippet to reduce duplication while preserving behaviour.",
        actual_output="<paste model response here>",
    )
    assert_test(test_case, [maintainability])

3. Run the evaluation

deepeval test run test_copilot_eval.py

4. Interpret results

When you run the evaluation, DeepEval produces terminal output similar to the following:

Running 2 test(s)...

  test_workflow_fix
    ✅ Correctness (score: 0.82, threshold: 0.5, passed: True)

  test_terraform_refactor
    ✅ Maintainability (score: 0.71, threshold: 0.5, passed: True)

======================= Results =======================
Tests run: 2, Passed: 2, Failed: 0
Overall pass rate: 100.0%

Metric scores:
  Correctness       avg: 0.82   min: 0.82   max: 0.82
  Maintainability   avg: 0.71   min: 0.71   max: 0.71
=======================================================

Each test case is scored on a 0 to 1 scale against your criteria. A score above the threshold you set counts as a pass. If a test fails, the output shows the reason so you can see where the model response fell short:

  test_workflow_fix
    ❌ Correctness (score: 0.34, threshold: 0.5, passed: False)
       Reason: The response did not identify the OIDC audience
       mismatch as the root cause and suggested unrelated
       permission changes instead.

To compare models, run the same test file once per model (swapping in each model's responses for actual_output) and record the results side by side:

Test case	Metric	Model A	Model B	Model C
test_workflow_fix	Correctness	0.82	0.91	0.64
test_terraform_refactor	Maintainability	0.71	0.78	0.69
Overall pass rate		100%	100%	50%

This gives you a quantitative basis for model comparison that you can track over time. You can also:

Add multiple metrics per test (correctness, security, maintainability).
Integrate tests into your CI/CD pipeline for regression checks when new models are released.
Export results to JSON for further analysis or dashboard reporting.

Define custom GEval metrics for each dimension in your scoring rubric to get automated scoring that aligns with your team's specific criteria.

Other Free Tools Worth Knowing

A few other open-source options are available if you want to explore further:

OpenAI Evals (https://github.com/openai/evals): a framework and registry of benchmarks for evaluating LLMs and LLM systems. Good for standardised benchmark testing.
LM Evaluation Harness (https://github.com/EleutherAI/lm-evaluation-harness): the backend behind the Hugging Face Open LLM Leaderboard. Supports 60+ academic benchmarks with API model support. Best suited for formal benchmark comparisons.

Recommended Team Operating Model

Use this cadence so your model decisions stay current:

Run a small benchmark set every month.
Run a fuller evaluation set each quarter.
Re-run when GitHub adds or retires major models.
Publish a one-page internal scorecard for your team.

A simple scorecard format:

Model	Avg quality	Avg latency	Cost proxy	Value score	Best-fit tasks
Model A	4.4	1.2s	1x	4.4	General coding
Model B	4.7	2.1s	3x	1.57	Deep debugging
Model C	4.1	0.9s	0.33x	12.42	Fast lightweight edits

This makes model selection transparent and easier to defend in architecture and governance reviews.

Final Thoughts

The model landscape in GitHub Copilot will keep moving. That is a feature, not a problem, if your team has a repeatable evaluation method.

Start with a small prompt set, apply a consistent scoring rubric, and review quality, latency, and cost together. Once your network sees the method in action, model choice becomes a practical engineering decision instead of a subjective debate.

Additional Resources

Supported AI models in Copilot: https://docs.github.com/en/copilot/reference/ai-models/supported-models
AI model comparison in Copilot: https://docs.github.com/en/copilot/reference/ai-models/model-comparison
Changing model in Copilot Chat: https://docs.github.com/en/copilot/using-github-copilot/ai-models/changing-the-ai-model-for-copilot-chat
DeepEval docs: https://deepeval.com/docs/getting-started
DeepEval GitHub: https://github.com/confident-ai/deepeval
OpenAI Evals: https://github.com/openai/evals
LM Evaluation Harness: https://github.com/EleutherAI/lm-evaluation-harness

Author

Marcel.LFollow

Microsoft MVP in DevTech - DevOps | DevOps Architect | Technical speaker focused on Microsoft technologies, Agentic AI, IaC & automation in Azure. Find me on GitHub: https://github.com/Pwd9000-ML

Like, share, follow me on: 🐙 GitHub | 🐧 X | 👾 LinkedIn

Date: 06-03-2026

GitHub Copilot Instructions vs Prompts vs Custom Agents vs Skills vs X vs WHY?

Marcel.L — Thu, 26 Feb 2026 09:09:32 +0000

GitHub Copilot Instructions vs Prompts vs Custom Agents vs Skills vs X vs WHY?

If you have been following my recent GitHub Copilot posts, you might have noticed a pattern. We have covered instructions, prompt files, skills, MCP, coding agents, and more. Each feature is powerful on its own. The confusing part is deciding which one to use for a specific problem.

This post is your practical decision guide.

We will compare:

Custom Instructions
Prompt Files
Custom Agents
Skills
MCP Servers
Hooks

The 60-Second Cheat Sheet

Primitive	Typical location	Scope	Best for	When not to use
Custom Instructions	`.github/copilot-instructions.md`, `.github/instructions/*.instructions.md`, `AGENTS.md`	Always-on or pattern-based	Team standards and default behaviour	One-off tasks or named workflows
Prompt Files	`.github/prompts/*.prompt.md`	Manual, on-demand slash command	Repeatable one-shot tasks	Multi-step runbooks with assets
Custom Agents	`.github/agents/*.agent.md`	Selected agent mode/persona	Specialised role plus tool control	General coding help or tiny tweaks
Skills	`.github/skills/<name>/SKILL.md`	On-demand and auto-discovered	Reusable multi-step workflows with resources	Simple standards or hard policy enforcement
MCP Servers	`.vscode/mcp.json` or user `mcp.json`	Tool and data connectivity	Live access to external systems and APIs	Static guidance that does not need external context
Hooks	`.github/hooks/*.json`	Agent workflow lifecycle events	Hard policy gates and safety controls	Soft guidance or stylistic preferences

If you remember one thing, remember this:

Instructions for always-on guidance.
Prompts for named one-off tasks.
Skills for reusable workflows.
Custom Agents for role and tool boundaries.
MCP for external live context.
Hooks for hard stop enforcement.

1) Custom Instructions: "Always apply these rules"

Use custom instructions when you want Copilot to behave consistently without repeating yourself in every chat.

What they are

Markdown instructions that are automatically added to context.
Three flavours:
- Global: .github/copilot-instructions.md applies to every chat request in the workspace.
- File/task-targeted: *.instructions.md files with an applyTo glob pattern or task description match. Store them in .github/instructions/.
- Multi-agent compatible: AGENTS.md in the workspace root is recognised by multiple AI agents (not only Copilot). Supports subfolder-level scoping for monorepos (experimental).
Instructions can also be shared at GitHub organisation level, so every repository in the org inherits a common baseline. (Note: Organisation-level instructions require a Copilot Business or Enterprise plan.)
Priority order when conflicts occur: personal (user-level) > repository > organisation.

Suitale Usage Examples

You want all IaC suggestions to follow your team's naming and tagging conventions, e.g. every resource must include environment and cost-centre tags.
You want consistent code style across the repo, e.g. British English in comments, four-space indentation, or a preferred import order.
You want secure defaults baked into every suggestion, e.g. private endpoints by default, no public IPs without justification, secrets always pulled from a vault.
You work with multiple AI agents and want a single AGENTS.md recognised by all of them, so rules are defined once and shared.

Do not use when

You only need a task once.
You need a named slash command.
You need a full runbook that includes extra scripts and templates.

Quick guide: which instruction type?

Type	When to reach for it
`copilot-instructions.md`	Single project, Copilot-only
`.instructions.md` + `applyTo`	Different rules for different file types or frameworks
`AGENTS.md`	Multi-agent workflows, or subfolder-level monorepo rules
Organisation instructions	Shared baseline across all repos in a GitHub org

DevOps example

"For all cloud IaC, always use least privilege, avoid hardcoded secrets, and follow approved resource naming conventions."

For a deeper walkthrough, see my earlier post: Instructions and Prompt Files to supercharge VS Code with GitHub Copilot

Official docs: Use custom instructions in VS Code

2) Prompt Files: "Run this specific play"

Prompt files are reusable slash commands for recurring tasks.

What they are

Markdown prompt files, usually in .github/prompts/*.prompt.md.
Invoked with / in chat, just like slash commands.
YAML frontmatter can define the agent, tools, model, and description.
Support built-in variables such as ${selection}, ${file}, and ${input:variableName} for dynamic context.
Can reference a custom agent via the agent field, inheriting that agent's tool set.

Suitale Usage Examples

You want a quick /security-review command that scans the current file for common misconfigurations such as open ports or missing encryption.
You want /generate-module to scaffold a new IaC module with consistent structure, inputs, outputs, and documentation every time.
You want /release-notes that always follows a fixed changelog format, pulling context from recent commits.
You want to override the default agent for a specific task by setting agent: plan in the frontmatter, e.g. a /design-review prompt that runs inside a planning-only agent.

Do not use when

You need always-on behavioural standards.
You need automatic discovery of a rich workflow with supporting resources.
You need deterministic enforcement logic.

DevOps example

Create /pipeline-hardening that checks secrets handling, approval gates, artifact integrity, and rollback readiness. Use ${input:environment} to let the user specify which environment to review.

Official docs: Use prompt files in VS Code

3) Custom Agents: "Use this specialist persona and tool set"

Custom Agents were previously known as custom chat modes.

What they are

Agent definition files in .github/agents/*.agent.md.
Define a specialist persona, instructions, allowed tools, and optional handoffs.
Designed for role-specific flows such as planning, review, or implementation.
Handoffs let you chain agents into guided workflows. After one agent finishes, a handoff button appears to transition to the next agent with pre-filled context. For example: Plan > Implement > Review.
Can run as subagents and can also be reused in background agents and cloud agents. (Note: The coding agent requires a Copilot Pro+, Business, or Enterprise plan.)
Can be shared at GitHub organisation level, so every repo in the org gets the same agent definitions. (Note: Organisation-level agent sharing requires a Copilot Business or Enterprise plan.)

Suitale Usage Examples

You want a Security Reviewer agent that can only read code and run linters but never edit files, e.g. a pre-merge review step that flags risks without changing anything.
You want a Planner agent that outputs a structured implementation plan and then hands off to an Implementation agent, giving the team a review checkpoint before code is written.
You want strict tool boundaries, e.g. an Auditor agent with access to cloud cost APIs and read-only file tools, but no ability to execute commands or apply changes.
You need a guided multi-step workflow where each stage has a different persona and tool set, such as Design > Build > Test.

Do not use when

You just need a short reusable prompt.
You only need default team standards.
You are trying to solve external data access without MCP.

DevOps example

A cost-optimiser.agent.md that only has read-only cloud and repo tools, then hands off to a separate implementation agent for approved changes. The handoff button appears automatically after the cost analysis completes.

Official docs: Custom agents in VS Code

4) Skills: "Package a reusable runbook"

Skills are where things get interesting for SRE and DevOps teams.

What they are

Folder-based capability packages with a required SKILL.md.
Stored in .github/skills/<skill-name>/ (workspace) or ~/.copilot/skills/ (personal, available across all workspaces).
Can include scripts, templates, references, and examples alongside the instructions.
Loaded progressively: Copilot reads name and description first, loads full instructions only when relevant, and accesses bundled resources on demand.
Portable: Skills follow the open Agent Skills standard. The same skill works across VS Code, GitHub Copilot CLI, and the GitHub Copilot coding agent.

Suitale Usage Examples

You want a repeatable incident triage workflow that walks through impact assessment, timeline capture, and owner assignment using a bundled template.
You want a postmortem assistant that generates a structured report with root-cause analysis, action items, and SLA impact, pulling from scripts and examples in the skill folder.
You want a CI/CD troubleshooting playbook the whole team can invoke, e.g. a skill that runs diagnostic scripts against a failed pipeline and suggests fixes.
You want cross-tool portability so the same workflow works in VS Code, the CLI, and the coding agent without maintaining separate definitions.

Do not use when

You only need a global coding rule.
You only need a tiny slash command with no supporting resources.
You need hard policy blocking behaviour.

DevOps example

A incident-triage skill that collects service impact, timeline, likely root causes, next actions, and owner assignments using a consistent template. The same skill can be invoked from the CLI during on-call triage and from VS Code during post-incident review.

My practical Skills deep dive: GitHub Copilot Skills: Reusable AI Workflows for DevOps and SREs

Official docs: Use Agent Skills in VS Code

5) MCP Servers: "Connect Copilot to live systems"

MCP is often the missing piece when people expect Copilot to access live external context.

What it is

MCP (Model Context Protocol) is an open standard for connecting AI models to external tools and services.
Configured in .vscode/mcp.json (workspace) or user profile mcp.json. Can also be installed from the VS Code MCP server gallery.
MCP servers can provide four categories of capability:
- Tools: Actions the agent can invoke (e.g. create an issue, query a database).
- Resources: Data the agent can pull into context (e.g. files, API responses, database rows).
- Prompts: Pre-configured prompt templates contributed by the server.
- MCP Apps: Interactive UI components such as forms and visualisations rendered directly in chat.
Organisations can centrally manage MCP server access via GitHub policies. (Note: Organisation-level MCP policy management requires a Copilot Business or Enterprise plan.)

Suitale Usage Examples

You need live GitHub data inside chat, e.g. listing open issues, checking workflow run status, or creating a PR directly from a conversation.
You need live cloud metadata, e.g. pulling resource tags, SKU availability, or cost estimates from Azure, AWS, or GCP during an architecture review.
You need external system context such as querying a database, pulling monitoring dashboards, or fetching ticket details from a service management tool.

Do not use when

Static instructions are enough.
The task is purely local code guidance.
You have not reviewed trust and security implications.

DevOps example

Use GitHub MCP to create issues and inspect workflow runs, then use a cloud-compatible MCP server to pull environment metadata for triage context.

My earlier MCP setup guide: Supercharge VSCode GitHub Copilot using Model Context Protocol (MCP) - Easy Setup Guide

Official docs: Add and manage MCP servers in VS Code

6) Hooks: "Enforce policy at execution time"

If instructions are advice, hooks are enforcement.

What they are

Deterministic shell commands that run at key strategic points in an agent's workflow.
Configured as JSON files in .github/hooks/*.json in your repository.
Available hook types include: sessionStart, sessionEnd, userPromptSubmitted, preToolUse, postToolUse, agentStop, subagentStop, and errorOccurred.
The preToolUse hook is the most powerful because it can approve or deny tool executions before they happen.
Hooks receive detailed JSON input about the agent's actions, enabling context-aware automation.
Work with both the Copilot coding agent on GitHub and GitHub Copilot CLI. (Note: The coding agent and CLI require a Copilot Pro+, Business, or Enterprise plan.)

Suitale Usage Examples

You need a hard control, not a recommendation, e.g. blocking any file edit that adds a public IP to IaC without an approved exception.
You must block risky operations unless a condition passes, e.g. deny bash commands that target production databases or delete cloud resource groups.
You need consistent compliance checks before agent actions proceed, e.g. validating that every new service deployment includes a required cost tag.
You want immutable audit logging of every tool invocation for regulatory or internal compliance, e.g. recording who ran what command and when.

Do not use when

A style guide or prompt convention is enough.
You do not need strict allow or deny behaviour.
You only need static behavioural guidance (use instructions instead).

DevOps example

A preToolUse hook that runs a security check script before any bash or edit tool call, blocking risky infrastructure changes in production unless required checks pass.

Official docs: About hooks for Copilot coding agent

So, Why This Many Primitives?

Because they solve different control layers:

Behaviour layer: Instructions
Task invocation layer: Prompt files
Persona and tool boundary layer: Custom agents
Workflow packaging layer: Skills
External connectivity layer: MCP
Policy enforcement layer: Hooks

This is not feature overlap. This is a composable system. You can mix and match:

A custom agent can reference instructions files via Markdown links so you do not duplicate rules.
A prompt file can set agent: to run inside a specific custom agent, inheriting its tool set.
A skill can bundle scripts that a custom agent or prompt file invokes.
An MCP server provides tools that any agent, prompt, or skill can call.
Hooks sit underneath everything, enforcing policy regardless of which primitive triggered the action.

The key insight is that each primitive has a different lifetime and trigger. Instructions are always on. Prompts are invoked manually. Skills are discovered automatically or by slash command. Agents set a persistent persona for a session. MCP provides live external data. Hooks enforce hard gates at execution time.

A Practical "When to Use What" Decision Flow

Walk through these questions in order. Pick the first match:

Do you need a rule applied to every chat request without anyone remembering to activate it? Instructions.
Do you need a named, repeatable task that people invoke on demand? Prompt File.
Do you need a specialist persona with a limited set of tools, or a multi-step handoff workflow? Custom Agent.
Do you need a reusable multi-step runbook with scripts, templates, or reference files bundled together? Skill.
Does the task require live data from an external system (GitHub API, cloud metadata, databases)? Add MCP.
Must a policy be enforced deterministically with no chance the model ignores it? Add a Hook.

Notice that 1 to 4 are "pick one" decisions, while 5 and 6 are additive layers you stack on top.

What a Mature DevOps Setup Looks Like

A practical stack for a platform engineering team might be:

Instructions: Workspace-level copilot-instructions.md for coding and security defaults. Scoped *.instructions.md files for IaC, pipeline YAML, and language-specific conventions.
Prompt files: 5 to 10 prompt files for common operational tasks such as /security-review, /release-notes, /changelog, and /generate-module.
Custom agents: 2 to 3 agents (planning, implementation, security review) connected via handoffs so the team flows from plan to code to review in one conversation.
Skills: 3 to 6 skills for triage, postmortems, runbook generation, and IaC change risk analysis. These work the same in VS Code, the CLI, and the coding agent.
MCP servers: GitHub MCP for issue and PR management, plus cloud-context MCP servers for pulling live environment metadata during triage.
Hooks: preToolUse hooks to block dangerous commands and postToolUse hooks for audit logging in autonomous coding agent workflows.

This combination gives you speed, consistency, and safety without forcing everything into one mechanism.

Final Thoughts

If you have ever asked "Should I use instructions, prompts, agents, or skills?", the answer is usually: use the smallest primitive that solves the actual problem.

Start simple:

Add instructions first for always-on standards.
Add prompt files when you catch yourself typing the same prompt repeatedly.
Add skills when a workflow needs bundled scripts and templates.
Add custom agents when you need role boundaries and handoff workflows.
Add MCP when the task requires live external data.
Add hooks where policy must be enforced, not suggested.

That is the difference between experimenting with Copilot and operationalising Copilot. Each primitive has a clear purpose, and together they form a composable customisation system.

Author

Marcel.LFollow

Microsoft MVP in DevTech - DevOps | DevOps Architect | Technical speaker focused on Microsoft technologies, Agentic AI, IaC & automation in Azure. Find me on GitHub: https://github.com/Pwd9000-ML

Like, share, follow me on: 🐙 GitHub | 🐧 X | 👾 LinkedIn

Date: 26-02-2026

GitHub Copilot Skills: Reusable AI Workflows for DevOps and SREs

Marcel.L — Tue, 24 Feb 2026 16:35:29 +0000

GitHub Copilot Skills: Reusable AI Workflows for DevOps and SREs

If you're a DevOps engineer or SRE, you probably have a handful of repeatable tasks that keep coming back: triaging failed pipelines, checking for risky Terraform changes, writing runbooks, and turning messy incident notes into something your team can actually use.

Until recently, you could get part of the way there with custom instructions and prompt files. They are both great, but they do not fully solve the same problem: packaging a repeatable, multi-step workflow with its own supporting assets.

This is where Agent Skills comes in. Agent Skills is an open standard (see agentskills.io) that works with GitHub Copilot in VS Code, Copilot CLI, and the Copilot coding agent.

In this post we will cover what Skills are, how to set them up in VS Code, and how to use them from beginner scenarios to more advanced DevOps and SRE use cases.

What Are GitHub Copilot Skills?

A Skill is an on-demand, reusable workflow for Copilot. A Skill lives in a folder, has a required SKILL.md, and can include supporting resources such as scripts, references, and templates.

At a high level, it is designed for:

Repeatable workflows you want to reuse across a team
Multi-step procedures that benefit from checklists and branching logic
Bundled assets such as scripts, templates, and short reference docs

The key idea is progressive loading:

Copilot first uses the Skill name and description for discovery.
If the request matches, it loads the Skill instructions.
It only loads extra resources when the Skill references them.

This makes Skills a good fit for DevOps because you can keep the default Copilot experience lean, then load a specialised runbook only when you need it.

Skills vs Prompts vs Instructions vs Agents vs Hooks

Skills sit in the same overall customisation system as instructions, prompt files, custom agents, and hooks. They are not a replacement. They are a different primitive.

Here is a practical DevOps-oriented way to think about them:

Primitive	Best for	DevOps example
Workspace instructions	Always-on standards	"Tag every Azure resource with `owner` and `env`"
File instructions	Standards for certain files	Helm chart defaults for `**/values.yaml`
Prompt files	One-shot tasks	"Summarise this sprint's deployment changelog"
Skills	Reusable workflows with assets	Kubernetes rollback playbook + kubectl scripts
Custom agents	Specialised role and tool limits	Cost-optimisation advisor (read-only)
Hooks	Deterministic enforcement	Reject Terraform plans that drop deletion protection

If you're new to Copilot customisation, my rule of thumb is:

Use instructions when you want Copilot to behave consistently all the time.
Use a prompt file when you want a reusable one-off command.
Use a Skill when you want a repeatable workflow that feels like a runbook.

Prerequisites

To use Skills effectively, you will want:

VS Code with GitHub Copilot enabled
A repo (or workspace) where you can commit the Skill folder so your team can share it

In VS Code chat, type /skills to open the Configure Skills menu and confirm VS Code can see your workspace Skills.

Skills can be stored in a few locations. For team usage, the simplest is the repository:

.github/skills/<skill-name>/SKILL.md

VS Code also recognises .claude/skills/ and .agents/skills/ as project skill directories. For personal skills that follow you across workspaces, use ~/.copilot/skills/.

If you want to share Skills across multiple repos, VS Code also supports additional search locations via the chat.agentSkillsLocations setting.

Your First Skill (Beginner Setup)

1) Create the folder

Create this structure:

.github/skills/incident-triage/
└── SKILL.md

2) Add SKILL.md

The front matter must match the folder name.

---
name: incident-triage
description: 'Triage production incidents and failed deployments. Use when: a pipeline fails, an alert fires, or you need an incident update for stakeholders.'
argument-hint: 'Optional: service name, environment, and alert link'
---

# Incident Triage

## When to Use

- Pipeline failed in `prod`
- Pager/alert fired and you need a first response
- You need a status update for stakeholders

## Procedure

1. Confirm the affected service, environment, and impact
2. Collect signal: alerts, recent deploys, logs, and error budgets
3. Identify likely root cause categories (deploy, dependency, infra, config)
4. Recommend next actions: rollback, mitigation, escalation
5. Write an incident update in a consistent format

## Output Format

Return:

- Impact summary
- Timeline
- Suspected causes
- Next actions
- Owner assignments

That is enough to get started. The Skill is now discoverable based on the description.

Using Skills in Chat

There are two ways Skills help you day-to-day:

Manual invocation: you can run the Skill as a slash command.
Automatic discovery: Copilot can decide to load the Skill when the request matches the description.

To invoke a Skill manually, type / in the chat input, pick the Skill, and then add any extra context. For example: /incident-triage payments-api prod https://alert-link.

You can control this with optional front matter:

user-invokable: false hides it from / commands
disable-model-invocation: true prevents automatic loading, but keeps slash use

This matters for teams. Some Skills are safe to auto-load. Others might be better as explicit, opt-in runbooks.

DevOps and SRE Use Cases (Practical)

Here are a few Skills that are genuinely useful in real operations.

Use Case 1: CI/CD Failure Triage

Goal: Standardise how you investigate failures and what you record.

A Skill can:

Ask for the workflow URL and failing job name
Require you to record whether it looks transient or deterministic
Produce a consistent issue template for follow-up

Use Case 2: Terraform Change Risk Review

Goal: Make IaC reviews consistent across a team.

A Skill can:

Require you to list affected environments
Check for risky patterns (public exposure, identity changes, state migration)
Output a simple go/no-go summary and required approvals

Use Case 3: Runbook Generator

Goal: Turn tribal knowledge into a maintained operational runbook.

A Skill can:

Enforce sections (Symptoms, Checks, Rollback, Escalation)
Add a "Safety" section (blast radius, data loss risk)
Produce a markdown runbook that matches your house style

Use Case 4: Postmortem Assistant

Goal: Reduce the time from incident to learning.

A Skill can:

Convert incident notes into a timeline
Extract contributing factors and remediation items
Enforce blameless language and clear action items

Advanced Patterns (Where Skills Get Interesting)

Once the basics work, Skills shine when you treat them like reusable operational modules.

1) Bundle references and templates

Keep SKILL.md short and link out to extra files in the same folder:

references/ for short docs you want to load on demand
assets/ for templates (issue templates, runbook templates)
scripts/ for small utilities

2) Keep descriptions keyword-rich

The description is the discovery surface. If you want the Skill to load for DevOps/SRE workflows, include words like:

incident, outage, on-call, pipeline, deployment, rollback
terraform, kubernetes, azure, aws, gcp
security review, compliance, audit

3) Decide which Skills auto-load

For teams, I recommend:

Auto-load for safe, low-risk guidance Skills (triage checklists)
Manual-only for high-impact Skills that might lead to edits or deployments

Real Examples You Can Explore

This repo already contains a working Skill you can inspect:

.github/skills/new-blog-post/SKILL.md in this repository

If you want ready-made public examples to learn from (without relying on GitHub code search), start here:

https://github.com/github/awesome-copilot (community collection)
https://github.com/anthropics/skills (reference skills)

Copy any skill folder into .github/skills/, then tweak the wording and guardrails until it matches how your team works.

If you want to find more public examples on GitHub, search for the folder pattern:

path:.github/skills SKILL.md

Note that GitHub code search may require you to sign in.

For the authoritative reference, see the VS Code documentation:

https://code.visualstudio.com/docs/copilot/customization/agent-skills

Tips for Adoption in DevOps Teams

Start with one runbook: pick a repetitive task (CI triage) and ship one Skill.
Treat Skills as code: version them, review changes, keep them short and intentional.
Measure outcomes: shorter time to triage, fewer repeated mistakes, better incident updates.
Keep it safe: do not turn every Skill into an autonomous actor. Default to guidance and checklists.

Conclusion

GitHub Copilot Skills are a practical way to turn the workflows in your head into something your whole team can reuse. For DevOps and SREs, that means more consistent triage, better runbooks, and faster, calmer incident response.

If you want, I can also turn the example incident-triage Skill into a full folder with templates and a lightweight script so you can drop it straight into .github/skills/.

Author

Marcel.LFollow

Microsoft MVP in DevTech - DevOps | DevOps Architect | Technical speaker focused on Microsoft technologies, Agentic AI, IaC & automation in Azure. Find me on GitHub: https://github.com/Pwd9000-ML

Like, share, follow me on: 🐙 GitHub | 🐧 X | 👾 LinkedIn

Date: 24-02-2026

GitHub Copilot SDK - Build AI-Powered DevOps Agents for Your Own Apps

Marcel.L — Tue, 17 Feb 2026 22:01:27 +0000

GitHub Copilot SDK: Build AI-Powered DevOps Agents for Your Own Apps

GitHub Copilot has steadily evolved from an in-editor autocomplete tool into a full-blown agentic platform. The latest step in that journey is the GitHub Copilot SDK, now available in Technical Preview. It lets you embed the same agent runtime that powers Copilot CLI directly into your own applications, scripts, and services using Python, TypeScript/Node.js, Go, or .NET.

For DevOps engineers, this opens up a powerful new pattern: instead of relying solely on Copilot inside your IDE or through GitHub Issues, you can now build custom AI agents that plug into your existing operational tooling. Think incident response bots, infrastructure validators, deployment assistants, and compliance checkers, all powered by the Copilot engine and your own custom tools.

In this post we will cover what the SDK is, how it works, how to get started, and walk through six practical DevOps use cases, several drawn from real open-source projects you can explore today.

What Is the GitHub Copilot SDK?

The GitHub Copilot SDK is a set of multi-platform libraries that expose the Copilot CLI agent runtime as a programmable interface. Rather than building your own LLM orchestration layer, you get the same production-tested engine that handles planning, tool invocation, file edits, and multi-turn conversations.

Key Facts

Detail	Value
Repository	github/copilot-sdk
Status	Technical Preview
Languages	TypeScript/Node.js, Python, Go, .NET
Licence	MIT
Auth	GitHub OAuth, environment variables (`GITHUB_TOKEN`), or BYOK
Billing	Counts against your Copilot premium request quota

Architecture

All four SDKs share the same communication model. Your application talks to the SDK client, which communicates with the Copilot CLI running in server mode over JSON-RPC:

Your Application
       ↓
  SDK Client
       ↓  JSON-RPC
  Copilot CLI (server mode)

The SDK manages the CLI process lifecycle automatically by default. You can also run the CLI externally in headless server mode and point multiple SDK clients at it, which is useful for shared development environments or debugging.

What You Can Do

Send prompts and receive responses (streaming or complete).
Define custom tools that the agent can call, with typed parameters and handler functions you control.
Connect to MCP servers (Model Context Protocol) to give the agent access to external services like the GitHub API, databases, or cloud provider tooling.
Create custom agents with specialised personas, system messages, and tool sets.
Use any supported model, including those available through Copilot or your own keys via BYOK (Bring Your Own Key) from providers like OpenAI, Azure AI Foundry, and Anthropic.

Getting Started

Prerequisites

GitHub Copilot subscription (Free tier with limited usage, or Pro/Pro+/Business/Enterprise). If using BYOK, no GitHub auth is required.
Copilot CLI installed and authenticated. Follow the Copilot CLI installation guide.
Your preferred language runtime: Node.js 18+, Python 3.8+, Go 1.21+, or .NET 8.0+.

Verify the CLI is working:

copilot --version

Install the SDK

Pick your language:

# Node.js / TypeScript
npm install @github/copilot-sdk

# Python
pip install github-copilot-sdk

# Go
go get github.com/github/copilot-sdk/go

# .NET
dotnet add package GitHub.Copilot.SDK

Your First Five Lines

Here is the simplest possible example in TypeScript. It creates a client, opens a session, sends a prompt, and prints the response:

import { CopilotClient } from '@github/copilot-sdk';

const client = new CopilotClient();
const session = await client.createSession({ model: 'gpt-4.1' });

const response = await session.sendAndWait({
  prompt: 'What is 2 + 2?',
});
console.log(response?.data.content);

await client.stop();
process.exit(0);

And the Python equivalent:

from github_copilot_sdk import CopilotClient

client = CopilotClient()
session = client.create_session(model="gpt-4.1")

response = session.send_and_wait(prompt="What is 2 + 2?")
print(response.data.content)

client.stop()

That is it. Five lines to get a Copilot-powered response in your own application.

Adding Streaming and Custom Tools

The real power of the SDK emerges when you add streaming responses and custom tools. Streaming gives your users real-time feedback while the agent works. Custom tools let the agent call functions you define, bridging the gap between the LLM and your operational systems.

Streaming Example (TypeScript)

import { CopilotClient } from '@github/copilot-sdk';

const client = new CopilotClient();
const session = await client.createSession({
  model: 'gpt-4.1',
  streaming: true,
});

session.on('assistant.message_delta', event => {
  process.stdout.write(event.data.deltaContent);
});
session.on('session.idle', () => {
  console.log();
});

await session.sendAndWait({
  prompt: 'Explain blue-green deployments in three sentences.',
});

await client.stop();
process.exit(0);

Custom Tool Example (TypeScript)

import { CopilotClient, defineTool } from '@github/copilot-sdk';

const checkPodStatus = defineTool('check_pod_status', {
  description: 'Check the status of Kubernetes pods in a namespace',
  parameters: {
    type: 'object',
    properties: {
      namespace: {
        type: 'string',
        description: 'The Kubernetes namespace',
      },
    },
    required: ['namespace'],
  },
  handler: async (args: { namespace: string }) => {
    // In a real scenario, call kubectl or the Kubernetes API here
    return {
      namespace: args.namespace,
      pods: [
        { name: 'api-server-1', status: 'Running', restarts: 0 },
        { name: 'api-server-2', status: 'CrashLoopBackOff', restarts: 12 },
        { name: 'worker-1', status: 'Running', restarts: 0 },
      ],
    };
  },
});

When the agent receives a question like "Are there any unhealthy pods in the production namespace?", it decides to call your check_pod_status tool, receives the result, and incorporates it into a natural-language response.

Connecting to MCP Servers

The SDK supports Model Context Protocol (MCP) servers out of the box. MCP provides a standardised way for AI agents to interact with external tools and data sources. This is especially relevant for DevOps because you can connect the agent to GitHub, cloud providers, databases, and monitoring APIs without writing custom tool handlers for each one.

For example, connecting to GitHub's MCP server gives the agent access to repositories, issues, pull requests, and more:

const session = await client.createSession({
  mcpServers: {
    github: {
      type: 'http',
      url: 'https://api.githubcopilot.com/mcp/',
    },
  },
});

You can also connect to local MCP servers. For example, an Azure Bicep schema server:

{
  "mcpServers": {
    "AzureBicep": {
      "type": "local",
      "command": "npx",
      "args": [
        "-y",
        "@azure/mcp@latest",
        "server",
        "start",
        "--namespace",
        "bicepschema",
        "--read-only"
      ]
    }
  }
}

The MCP Servers Directory maintains a growing catalogue of community servers, including integrations for Terraform, Docker, Prometheus, and many other DevOps-adjacent tools.

DevOps Use Cases

The SDK is still young, but the community is already building real tools with it. Here are six use cases, several drawn from actual open-source projects and the official cookbook, that show what is possible for DevOps teams.

Use Case 1: Autonomous SRE Agent for GitHub Actions

Real project: htekdev/github-sre-agent

This open-source project is a fully autonomous SRE agent built with the Copilot SDK. It listens for GitHub Actions webhook events and, when a workflow fails, it:

Fetches and analyses logs via the GitHub MCP server.
Checks GitHub system status to rule out platform outages.
Searches the web for known fixes using the Exa AI MCP server.
Makes an intelligent decision: retry a transient failure, create a detailed issue for a genuine bug, or skip if the failure is expected.
Tracks resolution: when a previously failed workflow succeeds, it automatically closes the related issue.

The architecture is clean and worth studying. It uses the Copilot SDK's createSession with two MCP servers (GitHub and Exa AI) plus custom tools for status checking, note-taking, and workflow tracking. Repository-level configuration lives in .github/sre-agent.yml:

version: 1
enabled: true
instructions: |
  - This repo uses pnpm, not npm
  - Always check if tests pass before suggesting retry
  - Create issues with label "ci-failure" for tracking
actions:
  retry:
    enabled: true
    maxAttempts: 3
  createIssue:
    enabled: true
    labels:
      - sre-agent
      - automated
      - ci-failure

This is a strong example of how the SDK can replace manual on-call triage for CI/CD failures.

Use Case 2: Repository Health Analysis (RepoCheckAI)

Real project: glaucia86/repocheckai (70+ stars)

RepoCheckAI (formerly Repo Doctor) is an agentic CLI tool built with the Copilot SDK that performs comprehensive health checks across six areas: documentation, developer experience, CI/CD, testing, governance, and security. It delivers a health score (0-100%), prioritised findings (P0/P1/P2), and actionable remediation steps with code snippets.

It offers two analysis modes:

Mode	How it works	Best for
Quick Scan	Analyses via GitHub API (up to 20 file reads)	Governance review, quick checks
Deep Analysis	Full source scan using Repomix	Code quality, architecture review

The killer feature for DevOps teams is the --issue flag. After analysis, it automatically creates structured GitHub Issues for each problem found, complete with priority labels, impact assessments, and fix instructions:

repocheck analyze your-org/your-repo --issue

# Creates:
# 🔴 [RepoCheckAI] docs: Missing README
# 🟠 [RepoCheckAI] ci: No CI/CD Pipeline
# 🟡 [RepoCheckAI] dx: Code Quality Issues

This pattern, using the SDK to audit repositories and create actionable issues, is directly applicable to platform engineering teams managing dozens of microservice repos.

Use Case 3: Autonomous Coding Loops (Ralph Loop Pattern)

Source: Official Copilot SDK Cookbook

The Ralph Loop is an autonomous development pattern from the SDK cookbook that is particularly powerful for DevOps automation. The concept: an AI agent iterates through tasks in isolated context windows, with state persisted on disk between iterations. Each loop creates a fresh session, reads the current state, does one task, writes results back, and exits.

import { readFile } from 'fs/promises';
import { CopilotClient } from '@github/copilot-sdk';

async function ralphLoop(promptFile: string, maxIterations: number = 50) {
  const client = new CopilotClient();
  await client.start();

  try {
    const prompt = await readFile(promptFile, 'utf-8');

    for (let i = 1; i <= maxIterations; i++) {
      console.log(`\n=== Iteration ${i}/${maxIterations} ===`);

      // Fresh session each iteration. Context isolation is the point
      const session = await client.createSession({
        model: 'gpt-4.1',
        workingDirectory: process.cwd(),
        onPermissionRequest: async () => ({ allow: true }),
      });

      try {
        await session.sendAndWait({ prompt }, 600_000);
      } finally {
        await session.destroy();
      }

      console.log(`Iteration ${i} complete.`);
    }
  } finally {
    await client.stop();
  }
}

ralphLoop('PROMPT.md', 20);

For DevOps, imagine pointing this at an IMPLEMENTATION_PLAN.md that lists infrastructure tasks: "add monitoring to service X", "update Terraform module Y to v2", "write integration tests for pipeline Z". The agent picks the next task, implements it, runs tests, commits, and moves on. The key principles:

Fresh context per iteration prevents context window degradation.
Disk as shared state (IMPLEMENTATION_PLAN.md) coordinates between iterations.
Backpressure (tests, builds, lints) ensures quality, the agent must pass them before committing.

This is ideal for burning down infrastructure debt or implementing a batch of related IaC changes unattended.

Use Case 4: Incident Response with PagerDuty and Datadog

Source: microsoft/copilot-sdk-samples

Microsoft's official sample repository includes dedicated PagerDuty and Datadog connector samples that demonstrate how to build incident management and monitoring agents. All connectors support a mock-first design, so you can develop and test without live credentials.

Here is how you might wire up an incident response agent that combines both:

import { CopilotClient, defineTool } from '@github/copilot-sdk';

// Tools backed by your PagerDuty and Datadog connectors
const getActiveIncidents = defineTool('get_active_incidents', {
  description: 'List active PagerDuty incidents for a service',
  parameters: {
    type: 'object',
    properties: {
      service: { type: 'string', description: 'Service name' },
    },
    required: ['service'],
  },
  handler: async (args: { service: string }) => {
    // In production, call PagerDuty API
    return {
      incidents: [
        {
          id: 'PD-4521',
          title: 'High error rate on payments-api',
          severity: 'P1',
          triggered: '2026-02-15T14:32:00Z',
          assignee: 'on-call-team',
        },
      ],
    };
  },
});

const queryMonitoring = defineTool('query_monitoring', {
  description: 'Query Datadog metrics and logs',
  parameters: {
    type: 'object',
    properties: {
      query: { type: 'string', description: 'Datadog query string' },
      timeRange: { type: 'string', description: 'Time range (e.g. last_1h)' },
    },
    required: ['query', 'timeRange'],
  },
  handler: async (args: { query: string; timeRange: string }) => {
    // In production, call Datadog API
    return {
      metrics: {
        errorRate: '12.4%',
        p99Latency: '2340ms',
        requestsPerSecond: 890,
      },
      recentLogs: [
        'ERROR: Connection pool exhausted for database replica-02',
        'WARN: Retry limit exceeded for downstream service auth-api',
      ],
    };
  },
});

const client = new CopilotClient();
const session = await client.createSession({
  model: 'gpt-4.1',
  streaming: true,
  tools: [getActiveIncidents, queryMonitoring],
  systemMessage: {
    content:
      'You are an incident response assistant. When asked about an incident, ' +
      'gather data from PagerDuty and Datadog, then provide: ' +
      '1) Incident timeline, 2) Affected services and metrics, ' +
      '3) Likely root cause, 4) Recommended remediation steps.',
  },
});

session.on('assistant.message_delta', event => {
  process.stdout.write(event.data.deltaContent);
});

await session.sendAndWait({
  prompt:
    'We have a P1 incident on payments-api. Pull the PagerDuty details and check Datadog for the last hour.',
});

await client.stop();
process.exit(0);

You could deploy this as a Slack bot, a Teams webhook, or a CLI tool for your on-call team. The agent correlates PagerDuty incident metadata with Datadog metrics and logs, then produces a structured summary with remediation steps.

Use Case 5: PR Age Visualisation and Repository Insights

Source: Official Copilot SDK Cookbook: PR Visualization

This cookbook recipe demonstrates a powerful pattern: using the SDK with zero custom tools. Instead, it relies entirely on the Copilot CLI's built-in capabilities, the GitHub MCP server for fetching PR data, file tools for saving charts, and code execution for generating visualisations.

The core setup is refreshingly simple. No defineTool calls, just a session with a system message and a prompt:

import { CopilotClient } from '@github/copilot-sdk';

const client = new CopilotClient({ logLevel: 'error' });

const session = await client.createSession({
  model: 'gpt-4.1',
  systemMessage: {
    content: `You are analyzing pull requests for the GitHub repository: ${owner}/${repo}.
Use the GitHub MCP Server tools to fetch PR data.
Use your file and code execution tools to generate charts.
Save any generated images to the current working directory.`,
  },
});

await session.sendAndWait({
  prompt: `Fetch the open pull requests for ${owner}/${repo} from the last week.
Calculate the age of each PR in days.
Generate a bar chart showing the distribution of PR ages.
Save the chart as "pr-age-chart.png".
Summarise the PR health - average age, oldest PR, and how many might be stale.`,
});

The agent uses the GitHub MCP server to list PRs, then generates a chart using Python/matplotlib. The interactive session lets you ask follow-up questions like "expand to the last month" or "group by author instead of age".

For DevOps leads, this pattern is gold. Build a scheduled job that runs this weekly and posts the chart to a Slack channel. No API integration code to maintain, just prompts.

Use Case 6: Infrastructure as Code Validation Agent

The problem: Your team maintains dozens of Terraform modules. Reviewing them for best practices, security compliance, and naming conventions is time-consuming and inconsistent.

The solution: Build a CLI tool that reads a Terraform directory and asks the Copilot agent to validate it against your organisation's policies.

import { CopilotClient, defineTool } from '@github/copilot-sdk';
import * as fs from 'fs';
import * as path from 'path';

const readTerraformFiles = defineTool('read_terraform_files', {
  description: 'Read all .tf files from a directory',
  parameters: {
    type: 'object',
    properties: {
      directory: {
        type: 'string',
        description: 'Path to the Terraform module directory',
      },
    },
    required: ['directory'],
  },
  handler: async (args: { directory: string }) => {
    const files = fs.readdirSync(args.directory).filter(f => f.endsWith('.tf'));
    const contents: Record<string, string> = {};
    for (const file of files) {
      contents[file] = fs.readFileSync(
        path.join(args.directory, file),
        'utf-8',
      );
    }
    return contents;
  },
});

const client = new CopilotClient();
const session = await client.createSession({
  model: 'gpt-4.1',
  streaming: true,
  tools: [readTerraformFiles],
  systemMessage: {
    content: `You are an infrastructure validation agent. When given a Terraform directory, read the files and check for:
1. All resources must include tags: Environment, Owner, CostCentre
2. No hardcoded secrets or credentials
3. Backend configuration must use remote state (azurerm or s3)
4. All variables must have descriptions and type constraints
5. Module sources must use version pinning
Report findings as a structured checklist with pass/fail for each rule.`,
  },
});

session.on('assistant.message_delta', event => {
  process.stdout.write(event.data.deltaContent);
});

await session.sendAndWait({
  prompt: 'Please validate the Terraform module at ./modules/networking',
});

await client.stop();

You could run this as a pre-commit hook, a CI step, or a standalone CLI that your platform team uses during module reviews. Combine it with the Ralph Loop pattern from Use Case 3 to validate and fix an entire library of modules autonomously.

Authentication Options

The SDK supports several authentication methods, giving you flexibility for different environments:

Method	Use Case
GitHub signed-in user	Local development; uses stored OAuth credentials from `copilot` CLI login
OAuth GitHub App	Web applications; pass user tokens from your GitHub OAuth app
Environment variables	CI/CD pipelines; set `COPILOT_GITHUB_TOKEN`, `GH_TOKEN`, or `GITHUB_TOKEN`
BYOK (Bring Your Own Key)	Air-gapped or custom environments; use your own API keys from OpenAI, Azure AI Foundry, or Anthropic

For CI/CD integration, environment variables are the most practical. For internal tools, the GitHub OAuth flow gives you per-user billing and audit trails.

Note: BYOK uses key-based authentication only. Microsoft Entra ID (Azure AD), managed identities, and third-party identity providers are not supported at this time.

Tips for DevOps Teams

Start with a well-defined problem. The SDK is not a magic box. It works best when you give the agent a clear task, the right tools, and a focused system message. "Analyse these logs and find errors" will outperform "do DevOps stuff."

Use system messages to encode your standards. The systemMessage field is your equivalent of a runbook. Tell the agent about your naming conventions, required tags, preferred tools, and escalation procedures.

Combine custom tools with MCP servers. Use MCP for standard integrations (GitHub API, cloud providers) and custom tools for your organisation-specific logic (internal APIs, proprietary systems).

Keep tools focused. Each tool should do one thing well. An agent with ten small, focused tools will perform better than one with three large, multi-purpose tools.

Review and validate. The SDK is in Technical Preview. Always review agent outputs before acting on them in production, especially for infrastructure changes or incident response recommendations.

Be mindful of billing. Each prompt counts against your Copilot premium request quota. For high-volume automation, consider batching requests and caching responses where appropriate.

Conclusion

The GitHub Copilot SDK brings agentic AI out of the IDE and into your operational tooling. For DevOps engineers, this means you can build custom agents that understand your infrastructure, your workflows, and your conventions, and embed them wherever they are most useful: CLI tools, chatbots, CI pipelines, or internal platforms.

The community is already proving the concept. Projects like github-sre-agent (autonomous CI/CD failure triage), RepoCheckAI (repository health analysis), and Microsoft's copilot-sdk-samples (PagerDuty and Datadog integrations) show that this is not theoretical. The official cookbook adds patterns like Ralph Loops for autonomous task iteration and PR visualisation using zero custom tools.

The SDK is currently in Technical Preview with support for Python, TypeScript, Go, and .NET, an MIT licence, and a growing ecosystem of MCP integrations. Whether you want to automate SRE workflows, audit repositories, triage incidents, or visualise PR health, the building blocks are ready.

Check out the GitHub Copilot SDK repository and the getting started guide to begin experimenting.

Author

Marcel.LFollow

Microsoft MVP in DevTech - DevOps | DevOps Architect | Technical speaker focused on Microsoft technologies, Agentic AI, IaC & automation in Azure. Find me on GitHub: https://github.com/Pwd9000-ML

Like, share, follow me on: 🐙 GitHub | 🐧 X | 👾 LinkedIn

Date: 17-02-2026

Using GitHub Copilot Coding Agent for DevOps Automation

Marcel.L — Sat, 14 Feb 2026 14:27:20 +0000

Using GitHub Copilot Coding Agent for DevOps Automation

As featured in Azure Spring Clean 2026

What if you could assign a GitHub Issue to an AI teammate and come back to a ready-to-review pull request? That is exactly what GitHub Copilot Coding Agent does. It works autonomously inside an ephemeral GitHub Actions environment, analyses your codebase, makes changes, runs tests, and opens a PR for your approval.

In this post we will look at how the coding agent works, how to set it up for a DevOps repository, and walk through six practical use cases you can try straight away.

What Is GitHub Copilot Coding Agent?

Think of the coding agent as an async, pull-request-oriented developer. You describe the work, it does the coding in the background, and you review the result. Here is the flow:

Assign the task via a GitHub Issue, PR comment, VS Code, or the GitHub CLI.
The agent spins up in an isolated GitHub Actions container with your setup workflow.
It explores, codes, and iterates, running builds, linters, and tests along the way.
A pull request appears with all changes, ready for your review.
You approve and merge. The agent can never merge its own work.

Security at a Glance

The agent is locked down by design:

Runs in ephemeral containers destroyed after each session.
Can only push to branches prefixed with copilot/, never to main or master.
Every PR is scanned by CodeQL for security issues, secret scanning for leaked credentials, and dependency checks against the GitHub Advisory Database.
The person who triggered the agent cannot approve the resulting PR, guaranteeing independent review.
Internet access is controlled by a default firewall. External services require explicit allow-listing.
Full audit trails of every action the agent took.

Key Limitations

Keep these in mind when planning tasks:

One repository, one PR per task. The agent cannot span multiple repos or open multiple PRs from a single issue.
Linux runners only (Ubuntu x64 GitHub Actions).
Read-only repo access within its sandbox. It writes to its copilot/ branch only.
No signed commits without a ruleset bypass for the agent.

For the full list of capabilities and constraints, see the official documentation.

Getting Set Up

You need a GitHub Copilot Pro, Pro+, Business, or Enterprise plan, write access to the repository, and GitHub Actions enabled. For organisations, an admin must enable the coding agent under Copilot settings.

Note: The coding agent uses both GitHub Actions minutes and Copilot premium requests. Keep an eye on usage through your billing settings.

1. Create the Setup Workflow

This workflow runs before the agent starts coding. It installs your project's dependencies so the agent can build and test. The job must be named copilot-setup-steps and live on your default branch:

# .github/workflows/copilot-setup-steps.yml
name: Copilot Setup Steps
on: workflow_dispatch

jobs:
  copilot-setup-steps:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Install dependencies
        run: |
          npm install
          # or: pip install -r requirements.txt

Important: Only steps, permissions, runs-on, services, snapshot, and timeout-minutes are honoured inside this job. Everything else is ignored.

If your workflows need secrets, add them through the copilot environment in repository Settings > Environments.

2. Add Custom Instructions

Create a .github/copilot-instructions.md file to teach the agent your team's conventions. This is the single biggest lever for improving output quality:

# Copilot Instructions

## Code Standards

- Use Terraform 1.6+ syntax
- All infrastructure must include tags: Environment, Owner, CostCentre

## Testing

- Terraform modules require terratest validation
- CI/CD changes need a dry-run in dev first

## Documentation

- Update CHANGELOG.md for infrastructure changes
- Include deployment runbooks for new services

You can also create scoped instruction files under .github/instructions/ with an applyTo glob, so rules only activate for matching files (for example, applyTo: "terraform/**").

3. Assign Your First Task

The simplest method: create a GitHub Issue, add @copilot as the assignee, and wait. The agent picks it up, works autonomously, and opens a PR when finished.

Other options:

PR comments: @copilot please add unit tests for this new module.
GitHub CLI: gh issue edit 42 --add-assignee @copilot
VS Code: Use the Copilot Chat panel or the GitHub sidebar to assign issues directly.

You can track progress through the Copilot Agents Panel on GitHub, which gives a real-time view of the session, including full logs of what the agent explored and changed.

DevOps Use Cases

Here is where things get interesting. These six scenarios show how the coding agent fits naturally into DevOps workflows.

Use Case 1: Fix a Broken CI/CD Pipeline

The problem: Your production deployment workflow failed overnight. Engineers are blocked.

Without the agent: Someone opens GitHub Actions, scrolls through hundreds of log lines, spots a missing environment variable, edits the YAML, pushes, waits for CI. Thirty to forty-five minutes gone.

With the agent: Create an issue like this:

Title: Fix failing production deployment workflow

Our deploy workflow failed on run #2847. The error appears to be in the AWS authentication step. Please investigate the logs, fix the workflow configuration, and validate the fix passes.

Assignee: @copilot

The agent analyses the logs, finds the missing AWS_DEPLOYMENT_ROLE reference, checks similar workflows for the correct pattern, updates the YAML, runs a validation build, and opens a PR with the fix. Your involvement? A five-minute code review.

Use Case 2: Enhance Infrastructure as Code

The problem: You need to add cluster auto-scaling to your EKS infrastructure across dev, staging, and prod.

With the agent:

Title: Add cluster auto-scaling to EKS infrastructure

Add Kubernetes Cluster Autoscaler to all three environments.

Acceptance criteria:

- Update Terraform modules with autoscaler config
- Set appropriate min/max node counts per environment
- Add CloudWatch alarms for scaling events
- Update IAM roles with required permissions
- Add terratest validation
- Document the scaling policies

Assignee: @copilot

The agent reads your existing modules, adds the autoscaler following AWS best practices, wires up environment-specific variables, writes tests, updates docs, and delivers one clean PR. You review, run terraform plan in your pipeline, and merge.

Use Case 3: Remediate Security Vulnerabilities

The problem: Dependabot flagged 15 vulnerabilities in your Node.js dependencies.

With the agent:

Title: Remediate active Dependabot security alerts

Please review all active security vulnerabilities, update dependencies to patched versions, and ensure all tests pass. Handle any breaking API changes from major version bumps and note them in the PR description.

Assignee: @copilot

The agent analyses each alert, updates package.json, runs npm audit and the full test suite, fixes any breakage from API changes, and opens a single PR with a clear summary of what changed and why.

Tip: Because the agent opens exactly one PR per task, consider creating separate issues for "safe patch updates" and "major version bumps with breaking changes" if you want to review them independently.

Use Case 4: Keep Documentation in Sync

The problem: Your docs drift out of date every time infrastructure changes land.

Solution: Trigger a documentation update automatically after infrastructure PRs merge:

# .github/workflows/doc-update.yml
name: Update Documentation
on:
  pull_request:
    types: [closed]
    paths:
      - 'terraform/**'
      - 'kubernetes/**'
      - '.github/workflows/**'

jobs:
  update-docs:
    if: github.event.pull_request.merged == true
    runs-on: ubuntu-latest
    steps:
      - name: Create Documentation Issue
        run: |
          gh issue create \
            --title "Update docs for PR #${{ github.event.pull_request.number }}" \
            --body "PR #${{ github.event.pull_request.number }} modified infrastructure. Please review and update relevant documentation, architecture diagrams, and deployment runbooks." \
            --assignee @copilot \
            --label "documentation"
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Every merged infrastructure PR spawns a documentation task that the agent handles. Your docs stay fresh without anyone having to remember.

Use Case 5: Boost Test Coverage on Autopilot

The problem: Your team knows test coverage is low, but writing tests for existing modules never makes it to the sprint.

With the agent: Create targeted issues for each area that needs coverage:

Title: Add unit tests for authentication module

The auth module at src/auth/ currently has minimal test coverage. Please:

1. Analyse the existing code and identify untested paths
2. Write comprehensive unit tests covering happy paths and edge cases
3. Ensure all tests pass and document any discovered bugs
4. Report the before/after coverage in the PR description

Assignee: @copilot

The agent reads the module, generates tests that exercise both success and failure paths, runs them to confirm they pass, and opens a PR with a coverage summary. Repeat across modules with separate issues and you can steadily burn down test debt in the background.

Tip: GitHub's own experiments with this pattern took test coverage from roughly 5% to near 100% across 45 days, producing over 1,400 tests. Small, daily PRs kept reviews manageable. See the Continuous AI blog post for details.

Use Case 6: Remediate Security Alerts via Campaigns

The problem: Your organisation runs security campaigns to address CodeQL or Dependabot findings at scale, but engineers struggle to find time for the fixes.

With the agent: From the Security tab on GitHub, select alerts and assign them directly to Copilot as part of a campaign. The agent receives the alert context, analyses the vulnerable code path, applies a fix, validates the change passes your test suite, and opens a PR, all without anyone filing a separate issue.

This is a first-class integration, not a workaround. The coding agent understands the alert metadata (CVE, severity, affected file and line) and uses it to produce targeted patches. For large campaigns spanning dozens of alerts, you can assign batches to Copilot and review the resulting PRs as they arrive.

Note: Security campaigns require GitHub Advanced Security or GitHub Code Security. The coding agent's own built-in security scanning (CodeQL, secret scanning, dependency checks) does not require these licences.

Tips for Getting the Best Results

Write clear issues. The quality of the PR directly reflects the quality of the issue. Include a problem statement, acceptance criteria, relevant file paths, and any constraints. A vague "make it faster" will produce vague results.

Iterate via PR comments. If the first attempt is not quite right, leave a review comment:

@copilot please use SSM Parameter Store instead of environment variables and add retry logic with exponential backoff.

The agent will push follow-up commits to the same PR.

Use custom instructions and scoped instruction files. The more context the agent has about your conventions (naming, tagging, testing patterns, preferred libraries), the better its output. This pays dividends across every task.

Always review thoroughly. The agent is a capable first-drafter, not an infallible engineer. Test changes in a non-production environment, verify security implications, and check for unintended side effects before merging.

Extending the Agent

MCP Servers

The coding agent ships with GitHub and Playwright MCP servers by default. You can add more through your repository settings or a .vscode/mcp.json file. For example, connecting an Azure MCP server gives the agent access to Bicep schema lookups:

{
  "mcpServers": {
    "AzureBicep": {
      "type": "local",
      "command": "npx",
      "args": [
        "-y",
        "@azure/mcp@latest",
        "server",
        "start",
        "--namespace",
        "bicepschema",
        "--read-only"
      ]
    }
  }
}

Custom Agents, Hooks, and Skills

Beyond custom instructions, you can create custom agents specialised for different tasks (frontend, docs, testing), define hooks that run shell commands at key points during execution, and package reusable skills with instructions and scripts. See the official docs on customising the coding agent for details.

Scheduled Maintenance

Automate recurring toil with a cron workflow:

# .github/workflows/weekly-maintenance.yml
name: Weekly Maintenance
on:
  schedule:
    - cron: '0 10 * * 5' # Friday 10 AM

jobs:
  maintenance:
    runs-on: ubuntu-latest
    steps:
      - name: Weekly dependency updates
        run: |
          gh issue create \
            --title "Weekly dependency updates" \
            --body "Review and update all dependencies. Run full test suite." \
            --assignee @copilot
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Try It Today

Pick one pain point in your current workflow and assign it to @copilot. Here is a template to get you started:

Title: Analyse and optimise CI/CD pipeline performance

@copilot please review our GitHub Actions workflows and:

1. Identify performance bottlenecks
2. Suggest and implement caching strategies
3. Add parallel job execution where possible
4. Summarise the improvements in the PR description

Assignee: @copilot

Start small, review the PR carefully, and build trust over time. As your team sees the results, you will naturally expand to more complex tasks.

Additional Resources

Author

Marcel.LFollow

Microsoft MVP in DevTech - DevOps | DevOps Architect | Technical speaker focused on Microsoft technologies, Agentic AI, IaC & automation in Azure. Find me on GitHub: https://github.com/Pwd9000-ML

Like, share, follow me on: 🐙 GitHub | 🐧 X | 👾 LinkedIn

GitHub Copilot Bootcamp: A Free Training Curriculum to Master AI-Powered Development

Marcel.L — Tue, 10 Feb 2026 11:33:29 +0000

GitHub Copilot Bootcamp: A Free Training Curriculum to Master AI-Powered Development

If you've ever felt overwhelmed by all the features GitHub Copilot offers, or wanted a structured, progressive path to go from "I've heard of Copilot" to "I use it to ship production code faster every single day," then this is for you.

I'm excited to share the GitHub Copilot Bootcamp, a comprehensive, open-source, training curriculum I've designed and curated to help developers at any experience level master GitHub Copilot through hands-on labs, real-world exercises, prompt examples, and weekly reflections.

The programme is completely free, self-paced, and publicly available as a GitHub template repository so you can fork it, adapt it for your team, or simply work through it on your own.

Why I Built This Bootcamp

Over the past year, through conference talks, workshops, and community sessions, I noticed a recurring pattern: developers were excited about GitHub Copilot but struggled to move beyond basic code completions. Many didn't know about the different interaction modes (Ask, Edit, Agent, Plan), prompt engineering techniques, or how Copilot can transform DevOps workflows and testing.

I wanted to create something that:

Starts from the fundamentals and progressively builds to advanced techniques
Prioritises doing over reading. Every week includes dedicated hands-on labs
Covers the full developer lifecycle, not just code generation, but testing, DevOps, refactoring, security, and ethics
Is easy for teams to adopt. The repo is a template with a facilitator guide, participant quickstart, and built-in feedback mechanisms

What You'll Learn: The Curriculum

The bootcamp is structured as a progressive learning journey. Each week builds on the previous one, so by the end you'll have a well-rounded mastery of GitHub Copilot across your entire development workflow.

📗 Week 1: Introduction and Developer Workflow Essentials

Duration: 2–2.5 hours | Objective: Build a solid foundation

Module	Duration	What You'll Cover
Understanding GitHub Copilot	30 min	Architecture, supported languages, real-world use cases, value proposition
Setup and Configuration	30 min	IDE installation, authentication, preferences, troubleshooting
Interaction Modes	15 min	Ask, Edit, Agent, and Plan modes, covering when and how to use each
Hands-On Lab	45–60 min	Explain, write, debug, and develop code by updating a real web application
Prompt Examples	Self-study	Inline completions, debugging, documentation generation patterns

Lab highlight: You'll work on a practical project, updating the "Mergington High School" extracurricular activities website, using all four interaction modes to solve real problems.

📘 Week 2: Advanced Development and Support Use Cases

Duration: 2–4 hours | Objective: Level up with prompt engineering and customisation

Module	Duration	What You'll Cover
Prompt Engineering Best Practices	45–60 min	The CRAFT framework, organisational standards, security recommendations
Advanced Developer Workflow	30–45 min	Documentation generation, Review-Refine-Iterate cycle, progressive refinement
Hands-On Lab	30–45 min	Set up custom instructions, build reusable prompt templates, configure custom agents
Prompt Examples	Self-study	Scaffolding, code generation with constraints, unit test generation, SQL patterns

Lab highlight: You'll customise your Copilot experience with repository-wide instruction files, targeted rules for specific file types, and reusable prompt templates. These are skills that pay dividends in every future session.

📙 Week 3: DevOps and Testing with Copilot

Duration: 2–2.5 hours | Objective: Streamline delivery and improve code reliability

Module	Duration	What You'll Cover
DevOps Automation	30–45 min	CI/CD pipeline generation, Infrastructure as Code (Docker, Kubernetes, Terraform)
Testing and Quality Assurance	30–45 min	Unit test generation, repeatable coverage, test optimisation and conversion
Hands-On Lab	60–90 min	Create CI/CD pipelines, generate Docker/K8s configs, build test suites with coverage
Prompt Examples	Self-study	GitHub Actions, GitLab CI, IaC prompts, security scanning, framework conversion

Lab highlight: This is where DevOps engineers will feel right at home. You'll use Copilot to generate real CI/CD pipelines, containerisation configs, and comprehensive test suites from scratch.

📕 Week 4: Refactoring, Optimisation, and Ethical Practices

Duration: 2–2.5 hours | Objective: Enhance code quality and adopt responsible AI practices

Module	Duration	What You'll Cover
Refactoring Large Codebases	30–45 min	Legacy code navigation, incremental refactoring, prompting patterns
Quality Refinements and Standards	30–45 min	Enforcing standards via Copilot, instruction files, automated quality checks
Ethical and Security Considerations	30–45 min	IP concerns, security vulnerabilities, responsible AI, organisational compliance
Hands-On Lab	45–60 min	Legacy code assessment, incremental refactoring with tests, pair refactoring exercises
Prompt Examples	Self-study	Security audit prompts, SOLID principles, bias detection, complete workflow patterns

Lab highlight: You'll tackle real legacy code, assessing it, documenting it, refactoring it incrementally with test coverage, and running security audits, all guided by Copilot.

How the Bootcamp Works

Self-Paced and Flexible

Work through the material at your own pace. Each week is designed as a standalone session of 2–4 hours, but you can split it across multiple sittings. The content is available 24/7 in the GitHub repository.

Built-In Feedback Loop

Every week includes structured reflection mechanisms:

Lab Reflections: Submit your lab experience via GitHub Issue templates built into the repository
Weekly Reflections: Capture key takeaways and areas for improvement through dedicated issue templates

This isn't just busywork. The reflections help solidify your learning and create a personal record of your Copilot journey.

Template Repository: Fork and Customise

The repository is set up as a GitHub template. If you're a team lead, trainer, or community organiser, you can:

Click "Use this template" to create your own copy
Customise the content for your organisation or audience
Use the included Facilitator Guide to deliver the training
Track participant progress through the built-in feedback issue templates

Companion Resources

The repo also includes:

IDE Support Guide, detailed information on Copilot features per IDE
Participant Quickstart, a quick reference card to get started immediately
Weekly Prompt Libraries, curated prompt examples for each topic area, serving as reference guides for self-study

Who Is This For?

This bootcamp is designed for developers at any experience level looking to accelerate their workflow with AI-assisted coding. Whether you're:

A junior developer wanting to learn Copilot from scratch
A senior engineer looking to formalise and deepen your Copilot usage
A DevOps engineer interested in AI-powered pipeline and infrastructure automation
A team lead searching for structured training material for your squad
A community organiser planning a Copilot workshop or meetup

…there's something here for you.

Note: You'll need an active GitHub Copilot subscription (Pro, Pro+, Business, or Enterprise) to complete the hands-on labs. Copilot features vary by IDE and version. The bootcamp references the Copilot feature matrix as the source of truth.

Get Started Today

Ready to level up your GitHub Copilot skills? Here's how to begin:

Visit the repository: github.com/Pwd9000-ML/GitHub-Copilot-Bootcamp
Star the repo ⭐ to bookmark it and show your support
Read the README to understand the full curriculum structure
Jump into Week 1 and start with "Understanding GitHub Copilot"
Complete the hands-on labs and submit your reflections
Share your progress, tag me on X or LinkedIn. I'd love to hear how it's going!

If you're a trainer or facilitator, check out the Facilitator Guide and use the template to spin up your own customised version.

Contributing

This bootcamp is open source under the MIT licence. If you spot improvements, have ideas for additional labs, or want to contribute prompt examples, check out the Contributing Guide and submit a pull request. Community contributions make this resource better for everyone.

Conclusion

The best way to learn GitHub Copilot isn't by reading about it. It's by using it. The GitHub Copilot Bootcamp gives you a structured, hands-on path to go from foundational understanding to advanced mastery across the entire development lifecycle: code generation, prompt engineering, DevOps automation, testing, refactoring, and responsible AI practices.

I've poured months of real-world experience from conferences, workshops, and production usage into this curriculum. I truly hope it accelerates your journey and makes AI-assisted development accessible and enjoyable.

Give it a try, and let me know what you think! 🚀

Author

Marcel.LFollow

Microsoft MVP in DevTech - DevOps | DevOps Architect | Technical speaker focused on Microsoft technologies, Agentic AI, IaC & automation in Azure. Find me on GitHub: https://github.com/Pwd9000-ML

Like, share, follow me on: 🐙 GitHub | 🐧 X | 👾 LinkedIn

Date: 10-02-2026

GitHub Copilot CLI: A DevOps Engineer's Practical Guide to AI-Powered Terminal Automation

Marcel.L — Tue, 27 Jan 2026 18:43:53 +0000

GitHub Copilot CLI: A DevOps Engineer's Practical Guide to AI-Powered Terminal Automation

As DevOps engineers, we live in the terminal, deploying infrastructure, debugging production issues, managing CI/CD pipelines, and orchestrating complex workflows. What if you could have an AI assistant directly in your command line that understands your context, writes scripts, debugs issues, and even interacts with GitHub.com on your behalf? Enter GitHub Copilot CLI, a powerful AI agent that brings GitHub Copilot's intelligence to your terminal, enabling you to automate DevOps tasks faster and more efficiently than ever before.

In this hands-on guide, we'll explore how to set up and leverage Copilot CLI to supercharge your DevOps workflows, from infrastructure automation to incident response and everything in between.

Why Copilot CLI Matters for DevOps Engineers

The traditional DevOps workflow involves context switching between documentation, Stack Overflow, man pages, and your terminal. Copilot CLI eliminates this friction by providing:

Contextual AI assistance: Copilot understands your project structure, Git history, and working directory
Code generation and modification: Create scripts, modify configuration files, and refactor code without leaving your terminal
GitHub integration: Manage issues, pull requests, workflows, and releases directly from the CLI
Intelligent troubleshooting: Debug failed builds, analyse logs, and suggest fixes based on error messages
Safe execution: Built-in permission system for file operations, shell commands, and network access
Iterative workflows: Work back-and-forth with the AI to refine solutions progressively

For DevOps teams, this means faster incident response, reduced context switching, consistent automation patterns, and the ability to handle complex multi-step tasks with simple natural language prompts.

Getting Started: Installation and Configuration

Before diving into practical use cases, let's get Copilot CLI set up properly. The tool is currently in public preview with data protection guarantees.

Prerequisites

Active GitHub Copilot subscription (Pro, Pro+, Business, or Enterprise)
PowerShell v6+ (Windows users)
Organization policy enabled (if using Copilot through an organization)

Important Note: This guide focuses on GitHub Copilot CLI (copilot command), which is distinct from the GitHub CLI (gh). Copilot CLI is the AI-powered terminal assistant, whilst GitHub CLI is for general GitHub API operations.

Installation Methods

Choose the installation method that fits your platform:

Windows (WinGet)

# Stable version
winget install GitHub.Copilot

# Prerelease version
winget install GitHub.Copilot.Prerelease

macOS/Linux (Homebrew)

# Stable version
brew install copilot-cli

# Prerelease version
brew install copilot-cli@prerelease

All Platforms (npm - requires Node.js 22+)

# Stable version
npm install -g @github/copilot

# Prerelease version
npm install -g @github/copilot@prerelease

macOS/Linux (Install Script)

# Standard installation
curl -fsSL https://gh.io/copilot-install | bash

# Or using wget
wget -qO- https://gh.io/copilot-install | bash

# Install as root to /usr/local/bin
curl -fsSL https://gh.io/copilot-install | sudo bash

# Custom directory installation
curl -fsSL https://gh.io/copilot-install | PREFIX="$HOME/.local" bash

Initial Authentication

After installation, authenticate with GitHub:

# Start Copilot CLI
copilot

# On first launch, you'll be prompted to login
/login

Follow the on-screen instructions to authenticate via your browser. Alternatively, you can use a fine-grained personal access token with the "Copilot Requests" permission:

# Set the token in your environment (GH_TOKEN takes precedence over GITHUB_TOKEN)
export GH_TOKEN="your_token_here"
# Or use GITHUB_TOKEN
export GITHUB_TOKEN="your_token_here"

# Or add to your shell profile (.bashrc, .zshrc, etc.)
echo 'export GH_TOKEN="your_token_here"' >> ~/.bashrc

Verification

Verify your installation:

copilot --version

You're now ready to start using Copilot CLI! For comprehensive documentation, refer to the official GitHub Copilot CLI documentation.

Understanding Copilot CLI Modes

Copilot CLI operates in two distinct modes, each suited for different DevOps workflows:

1. Interactive Mode (Default)

Start an interactive session where you can work iteratively with Copilot:

copilot

This mode is ideal for:

Exploratory tasks and troubleshooting
Multi-step workflows requiring feedback
Learning and experimentation
Complex tasks where you need to review each step

2. Programmatic Mode

Execute single prompts directly from the command line:

copilot -p "Show me this week's Git commits and summarize them" --allow-tool 'shell(git)'

# Pipe output from scripts
./generate-prompt.sh | copilot

This mode is perfect for:

CI/CD pipeline integration
Scripted automation
One-off tasks in scripts
Batch operations

Security Note: When using automatic approval flags like --allow-all-tools, Copilot has the same access as your user account. Use with caution in production environments.

Practical DevOps Use Cases: Step-by-Step

Let's explore real-world scenarios where Copilot CLI shines in DevOps workflows.

Use Case 1: Infrastructure as Code (IaC) Development

Scenario: You need to create a Terraform module for an Azure Kubernetes Service (AKS) cluster with monitoring and security best practices.

Step 1: Start Copilot CLI in your project directory

cd ~/projects/terraform-azure-aks
copilot

Step 2: Trust the directory when prompted (choose option 2 if you trust this directory for future sessions)

Step 3: Provide a natural language prompt

Create a Terraform module in the modules/aks directory that provisions an Azure Kubernetes Service cluster with the following requirements:
- Use Azure CNI networking
- Enable Azure Monitor Container Insights
- Configure Azure Active Directory integration
- Use managed identity
- Enable node auto-scaling (1-5 nodes)
- Include proper variable definitions and outputs
- Follow Terraform best practices

Step 4: Review the files Copilot creates and approve operations

Copilot will ask permission to:

Create directory structure
Write .tf files (main.tf, variables.tf, outputs.tf)
Set file permissions

Step 5: Iterate and refine

Add a locals.tf file with common tags for all resources, including environment, managed-by, and cost-center tags

Step 6: Validate the configuration

Run terraform init and terraform validate in the modules/aks directory

Copilot will execute the commands and report any issues, which you can then ask it to fix.

Use Case 2: CI/CD Pipeline Creation and Debugging

Scenario: Create a GitHub Actions workflow that runs tests, builds a Docker image, and deploys to Azure Container Apps.

Step 1: Generate the workflow

copilot

Create a GitHub Actions workflow file that:
1. Triggers on push to main and pull requests
2. Runs unit tests with pytest
3. Builds a Docker image
4. Pushes to Azure Container Registry
5. Deploys to Azure Container Apps
6. Uses GitHub secrets for Azure credentials
7. Includes proper caching for dependencies

Step 2: Copilot creates .github/workflows/deploy.yml

Review and approve the file creation. Copilot will structure the workflow with proper jobs, steps, and best practices.

Step 3: Debug a failing workflow

When your workflow fails, analyse it with Copilot:

Check the last failed run of the deploy workflow and explain what went wrong

Copilot fetches the workflow run logs, analyses the failure, and suggests fixes:

The workflow failed because the Azure Container Registry login step is missing the registry name. Fix this in the workflow file.

Step 4: Automatically fix and commit

Fix the workflow file and create a pull request with the fix

Copilot makes the changes and creates a PR on GitHub.com for you to review.

Use Case 3: Incident Response and Log Analysis

Scenario: You're responding to a production incident and need to analyse application logs quickly.

Step 1: Aggregate and analyse logs

copilot

Read the last 500 lines from /var/log/app/application.log, filter for ERROR level messages from the last hour, group them by error type, and show the top 5 most frequent errors with their counts

Step 2: Investigate a specific error pattern

I see "Database connection timeout" errors. Check the database connection configuration in @config/database.yml and suggest fixes based on the error pattern

Step 3: Generate a runbook entry

Create a markdown runbook entry in docs/runbooks/database-timeouts.md documenting this issue, the investigation steps, and the solution. Include the commands used for diagnosis.

Step 4: Create a monitoring alert

Based on this incident, create a GitHub Actions workflow that monitors the application log for database connection timeouts and creates an issue if the error rate exceeds 10 per hour

Use Case 4: Managing GitHub Operations at Scale

Scenario: Manage multiple repositories, issues, and pull requests across your organization.

Step 1: Audit open pull requests

copilot

List all open pull requests across my-org/infrastructure-* repositories that have been open for more than 7 days and haven't been updated in the last 3 days

Step 2: Batch operations

For each PR in the list, add a comment asking the author for an update and assign the "needs-attention" label

Step 3: Repository maintenance

In my-org/terraform-modules, check if there are any open dependabot PRs. If they pass CI and are patch or minor version updates, merge them automatically.

Step 4: Issue triaging

Create a report showing all critical severity issues across my-org repositories that are unassigned. Save it as triage-report-2026-01-27.md

Use Case 5: Script Generation and Automation

Scenario: Generate operational scripts for common DevOps tasks.

Step 1: Create a backup script

copilot

Create a bash script called backup-postgres.sh that:
- Takes database name, host, and output directory as arguments
- Uses pg_dump to create a backup
- Compresses the backup with gzip
- Names the file with a timestamp
- Rotates backups (keeps only the last 7 days)
- Logs operations to /var/log/backup.log
- Includes error handling and exit codes
- Has usage instructions in comments

Step 2: Create a deployment script

Create a Python script deploy-app.py that:
- Accepts environment (dev/staging/prod) as argument
- Validates the environment configuration
- Builds the Docker image
- Tags it appropriately
- Pushes to the registry
- Updates the Kubernetes deployment
- Waits for rollout to complete
- Rolls back if health checks fail
- Includes comprehensive logging

Step 3: Generate monitoring checks

Create a health-check script that tests our microservices (API, database, Redis, message queue) and outputs results in JSON format suitable for Prometheus

Use Case 6: Documentation and Knowledge Management

Scenario: Maintain up-to-date documentation for your infrastructure.

Step 1: Generate architecture documentation

copilot

Analyse the Terraform files in the infrastructure/ directory and create a comprehensive architecture.md document describing our cloud infrastructure, including diagrams in Mermaid format, resource dependencies, and data flows

Step 2: Update README files

Review all README.md files in this repository and update them to include current setup instructions, dependencies, and examples based on the actual code

Step 3: Create API documentation

Analyse the FastAPI application in src/api/ and generate OpenAPI documentation with examples for each endpoint

Advanced Tips and Best Practices

1. Use File References

Include specific files in your prompts using @:

Explain the pipeline configuration in @.github/workflows/ci.yml and suggest optimizations

2. Manage Working Directories

Switch directories without leaving your session:

/cwd ~/projects/kubernetes-configs

Add additional trusted directories:

/add-dir /home/user/shared-scripts

3. Direct Shell Commands

Run shell commands directly with !:

!kubectl get pods -n production

4. Custom Instructions

Enhance Copilot's understanding by adding custom instructions to your repository. Copilot CLI supports multiple instruction formats:

Repository-wide instructions: .github/copilot-instructions.md
Path-specific instructions: .github/instructions/**/*.instructions.md
Agent files: AGENTS.md in your repository root

Create .github/copilot-instructions.md:

# DevOps Team Instructions

## Our Stack

- Cloud: Azure (Primary), AWS (Legacy)
- Orchestration: Kubernetes (AKS)
- IaC: Terraform
- CI/CD: GitHub Actions
- Monitoring: Prometheus, Grafana, Azure Monitor

## Conventions

- All Terraform modules use semantic versioning
- Kubernetes manifests use Kustomize overlays
- Scripts must include error handling and logging
- Follow the repository's existing naming conventions

## Best Practices

- Always include resource tags: environment, cost-center, managed-by
- Use managed identities instead of service principals
- Enable diagnostic settings on all Azure resources

5. Session Management

Resume previous sessions:

# Resume the most recent session
copilot --continue

# Browse and select from available sessions
copilot --resume

6. Delegate to Copilot Coding Agent

For complex multi-file changes, delegate to the more powerful Copilot coding agent:

/delegate Refactor the Terraform modules to use Azure Verified Modules (AVM) standards and update all references

This creates a draft PR where Copilot coding agent works in the background and requests your review when complete.

7. Security Permissions

Control what Copilot can access:

# Allow all paths (use with caution)
copilot --allow-all-paths

# Allow all URLs (use with caution)
copilot --allow-all-urls

# Pre-approve specific domains
copilot --allow-url github.com --allow-url api.github.com

# Allow specific tools without confirmation
copilot -p "Backup the database" --allow-tool 'shell(pg_dump)'

8. Context Management Commands

Copilot CLI provides slash commands to monitor and manage your context window:

/usage - View session statistics (premium requests used, duration, lines edited, token breakdown)
/context - Visual overview of current token usage
/compact - Manually compress conversation history to free up context space

Note: Copilot CLI automatically compresses history when approaching 95% of the token limit and warns you when less than 20% remains.

9. Model Selection

Switch models during your session:

/model

Select from the available models. Each submission reduces your monthly premium request quota by the multiplier shown (e.g., Claude Sonnet 4.5 (1x) = 1 premium request per prompt).

10. Built-in Custom Agents

Copilot CLI includes specialised agents for common tasks:

Agent	Purpose
Explore	Quick codebase analysis without adding to main context
Task	Execute commands (tests, builds) with brief summaries
Plan	Analyse dependencies and create implementation plans
Code-review	Review changes, surfacing only genuine issues

Use them with:

/agent

Or call them directly in prompts: Use the Plan agent to analyse how to refactor the authentication module

11. Extend with MCP Servers

Copilot CLI comes with the GitHub MCP server pre-configured. Add more MCP servers to extend functionality:

/mcp add

Fill in the server details and press Ctrl+S to save. Server configurations are stored in ~/.copilot/mcp-config.json.

Real-World DevOps Workflow Integration

Morning Standup Prep

copilot -p "Summarise my work from yesterday: show commits, closed PRs, and completed issues from all my-org repositories" --allow-all-urls

Deployment Checklist

copilot

Create a deployment checklist for the v2.3.0 release:
1. Verify all tests pass in CI
2. Check database migration scripts
3. Review open security issues
4. Confirm rollback procedure is documented
5. List all changed configuration values
6. Generate release notes from PR descriptions

Post-Incident Review

copilot

Based on the incident timeline in docs/incidents/2026-01-27-outage.md:
1. Create a root cause analysis document
2. Generate corrective action items as GitHub issues
3. Update the runbook with new procedures
4. Create a monitoring alert to prevent recurrence

Infrastructure Audit

copilot

Audit our Terraform state files and list:
- Resources without required tags
- Resources in non-compliant regions
- Unencrypted storage accounts
- Public IP addresses
Generate a compliance report in CSV format

Common Pitfalls and How to Avoid Them

1. Over-Trusting Automatic Approval

Problem: Using --allow-all-tools without understanding the risks.

Solution: Use granular approval flags in scripts:

copilot -p "Deploy to staging" \
  --allow-tool 'shell(kubectl)' \
  --allow-tool 'shell(helm)' \
  --allow-url 'staging.example.com'

2. Not Using Custom Instructions

Problem: Copilot generates solutions that don't match your team's conventions.

Solution: Maintain .github/copilot-instructions.md with your standards and update it regularly.

3. Forgetting to Review Generated Code

Problem: Blindly accepting generated scripts without understanding them.

Solution: Always ask Copilot to explain complex code:

Explain the script you just created line by line, especially the error handling logic

4. Not Leveraging Iteration

Problem: Expecting perfect results on the first attempt.

Solution: Work iteratively with Copilot:

Good start, but modify the script to:
- Use jq for JSON parsing instead of grep
- Add progress indicators
- Exit with non-zero code on failure

Measuring the Impact

Track how Copilot CLI improves your DevOps workflows:

Time Savings

Before: 30 minutes to write a deployment script with proper error handling
After: 5 minutes to generate, review, and test with Copilot CLI

Error Reduction

Before: Manual script writing leads to missed edge cases
After: Copilot suggests best practices and error handling patterns

Knowledge Sharing

Before: Tribal knowledge in senior engineers' heads
After: Captured in prompts, custom instructions, and generated runbooks

Consistency

Before: Each engineer writes scripts differently
After: Standardised patterns through custom instructions

Conclusion

GitHub Copilot CLI represents a paradigm shift in how DevOps engineers interact with their terminal. By bringing AI assistance directly into your workflow, it enables you to work faster, make fewer mistakes, and spend more time on strategic work rather than repetitive tasks.

Your Action Plan

Install Copilot CLI today using your preferred method
Start small: Use it for simple tasks like generating scripts or analysing logs
Add custom instructions to align Copilot with your team's practices
Integrate into daily workflows: Make Copilot CLI part of your standup, deployment, and incident response processes
Share learnings: Document effective prompts and patterns for your team
Measure impact: Track time saved and productivity improvements

Resources for Further Learning

Tip: Use the /feedback slash command in an interactive session to submit feedback, report bugs, or suggest new features directly to GitHub.

The future of DevOps is conversational, start the conversation with Copilot CLI today!

Author

Marcel.LFollow

Microsoft MVP in DevTech - DevOps | DevOps Architect | Technical speaker focused on Microsoft technologies, Agentic AI, IaC & automation in Azure. Find me on GitHub: https://github.com/Pwd9000-ML

Like, share, follow me on: 🐙 GitHub | 🐧 X | 👾 LinkedIn

GitHub Skills: Your Complete Learning Path to AI-Powered Development

Marcel.L — Fri, 23 Jan 2026 00:19:05 +0000

Unlock Your Development Potential with GitHub Skills

Are you ready to transform your development journey? Whether you're just starting out with Git and GitHub, or looking to master AI-powered development with GitHub Copilot, GitHub Skills is your free, hands-on learning platform that will guide you every step of the way.

In this comprehensive guide, I'll walk you through everything you need to know about GitHub Skills, show you exactly where to start, and reveal the certification paths that can validate your expertise in AI-assisted development. Let's embark on this exciting learning adventure together!

Why GitHub Skills Matters for Your Career

In today's rapidly evolving tech landscape, understanding GitHub and AI-powered development tools isn't just an advantage, it's becoming essential. Consider this: GitHub serves over 100 million developers worldwide, and companies like Shopify, Stripe, Coca-Cola, and General Motors are using GitHub Copilot to accelerate their development. Here's why GitHub Skills should be your go-to learning resource:

Hands-on Learning: No more passive video watching. GitHub Skills provides interactive, practical courses where you learn by doing real work in actual repositories. As the platform says: "Learning should be fun, there are no simulations or boring tutorials here, just hands-on lessons created by GitHub and taught with GitHub Actions."
Free and Accessible: All courses are completely free and available to anyone with a GitHub account.
Self-Paced: Learn at your own speed, on your own schedule, without pressure or deadlines.
Real Workflow Experience: Everything happens with real GitHub features, Issues, Actions, Codespaces, and Pull Requests, giving you genuine experience.
Industry-Standard Tools: Master the same tools and workflows used by millions of developers worldwide.
AI-Ready Skills: Get ahead of the curve with courses specifically designed for GitHub Copilot and AI-assisted development.

Your Learning Journey: Where to Start

Absolute Beginners: Master the Fundamentals

If you're new to GitHub or version control, start here:

Introduction to GitHub - Learn the basics of GitHub, repositories, branches, commits, and pull requests. This is your foundation!
Communicate using Markdown - Master the formatting language that powers README files, issues, and documentation across GitHub.
GitHub Pages - Build and host your first website directly from a GitHub repository.
Review Pull Requests - Learn the collaborative review process that's central to team development.

Intermediate Learners: Level Up Your Skills

Once you're comfortable with the basics, tackle these courses:

Introduction to Git - Deep dive into Git version control using the command line (CLI) and VS Code.
Resolve Merge Conflicts - Handle one of the most common challenges in collaborative development.
Release-based Workflow - Learn how to manage software releases professionally.
Connect the Dots - Understand how to link issues, pull requests, and conversations.
GitHub Actions: Hello World - Begin your automation journey with CI/CD pipelines.
Test with Actions - Create workflows that enable Continuous Integration (CI) for your projects.
Secure Code Game - A GitHub Security Lab initiative where you secure intentionally vulnerable code. Gamified learning at its best!

Mastering GitHub Copilot: The AI Revolution

Now for the exciting part! AI-powered development! GitHub Copilot is transforming how we write code, and GitHub Skills has four dedicated courses to help you harness its full power:

1. Getting Started with GitHub Copilot

This essential foundation course (428+ stars!) teaches you how to:

Set up and configure GitHub Copilot in VS Code
Use AI suggestions effectively to accelerate your coding
Understand Copilot's capabilities and limitations
Write better prompts to get more accurate code suggestions
Integrate AI assistance into your daily workflow

2. Customize Your GitHub Copilot Experience

Take Copilot to the next level in under 30 minutes! Learn to:

Set up repository-wide custom instructions for project context
Create targeted custom instructions for specific file types and directories
Build reusable prompt templates for common tasks
Configure custom agents for specialised workflows

3. Integrate MCP with GitHub Copilot

Expand Copilot's capabilities with the Model Context Protocol (MCP):

Set up a GitHub MCP server with Copilot
Delegate Copilot to research projects and manage issues
Create pull requests from idea to implementation
Unlock advanced AI-assisted workflows

4. Expand Your Team with Copilot Coding Agent

The most cutting-edge course! Let Copilot tackle issues directly on GitHub:

Assign issues to Copilot and let it autonomously write code
Review and collaborate on Copilot's work
Provide feedback and iterate with your AI teammate
Work on multiple issues in parallel

Note: This course requires GitHub Copilot Pro or higher subscription.

Key Skills You'll Develop:

Prompt Engineering: Learn how to communicate your intent clearly to get the best AI-generated code
Code Review with AI: Understand how to review and validate AI-suggested code
Productivity Acceleration: Discover workflows that can dramatically accelerate development. Companies like Grupo Boticário report 94% increased developer productivity with Copilot!
Best Practices: Learn when to use Copilot and when to rely on your own expertise

Want a structured, hands-on deep dive? Check out the GitHub Copilot Bootcamp, a free, open-source 4-week training curriculum I created that takes you from setup to advanced prompt engineering, DevOps automation, refactoring, and ethical AI practices, complete with labs and exercises. Read more about it in my blog post: GitHub Copilot Bootcamp: A Free Training Curriculum to Master AI-Powered Development.

Certifications: Validate Your AI Development Expertise

GitHub now offers professional certifications that can significantly boost your career prospects. According to the 2025 Pearson VUE Value of IT Certification report:

79% of certified employees produce higher quality work
70% demonstrated improved productivity
32% received salary increases
82% gained confidence to explore new job opportunities

These certifications are recognised industry-wide and demonstrate your proficiency with modern development tools.

GitHub Certification Path

GitHub offers five professional certifications, available in English, Portuguese, Spanish, Korean, and Japanese:

GitHub Foundations Certification: Start with the fundamentals. Prove your knowledge of repositories, collaboration, and GitHub features. Perfect for users who want to validate their foundational understanding.
GitHub Actions Certification: Designed for DevOps engineers, software developers, and IT professionals with intermediate experience in workflow creation, automation, and CI/CD pipeline management.
GitHub Copilot Certification: This exam evaluates your skill in using the AI-driven code completion tool in various programming languages, certifying your capability to optimise software development workflows efficiently.
GitHub Advanced Security Certification: For individuals with deep understanding of GitHub security features and hands-on experience securing software development workflows.
GitHub Administration Certification: Designed for system administrators, software developers, and IT professionals with intermediate-level experience in GitHub Enterprise Administration.

Microsoft Applied Skills Credentials

In addition to traditional certifications, Microsoft Learn offers Applied Skills credentials that demonstrate practical abilities:

Accelerate app development by using GitHub Copilot: Prove your ability to leverage Copilot for real-world app development.
Automate Azure Load Testing by using GitHub Actions: Demonstrate automation skills in real-world scenarios.

Why Get Certified?

Career Advancement: Stand out in job applications and promotions
Skill Validation: Prove your expertise to employers and clients
Community Recognition: Join an elite group of certified GitHub professionals
Continuous Learning: Stay updated with the latest GitHub features and best practices

Pro Tip: Visit the GitHub Certifications page to explore current certification options. Exams are available via Pearson VUE testing centres or online.

Free Access for Students and Educators

If you're a student or educator, GitHub has amazing news for you! GitHub Education provides:

For Students:

Free GitHub Copilot Pro for verified students. The same tools professionals pay for!
GitHub Student Developer Pack with free access to premium developer tools
Join a community of 5+ million students worldwide
Campus Experts Program to develop leadership skills

For Educators:

GitHub Classroom to create virtual classrooms, manage assignments, and automate grading
Connect with 200K+ verified educators globally
Free access to GitHub Enterprise for educational institutions

"GitHub Education bridges the gap between coding education and a tech career, and is accessible to everyone globally at no cost."

Join GitHub Education to verify your student or educator status and unlock these benefits!

GitHub Copilot Free Tier: Start Today

Not a student? No problem! GitHub now offers a free tier for everyone:

50 agent mode or chat requests per month
2,000 code completions per month
Access to Haiku 4.5, GPT-4.1, and more AI models

This is perfect for getting started and experiencing AI-powered development before deciding if you need the Pro features.

Get started with Copilot Free

Your Action Plan: Start Learning Today

Ready to begin? Here's your step-by-step action plan:

Week 1: Foundation Building

Create your GitHub account (if you haven't already)
Complete Introduction to GitHub
Set up your first repository and make your first commit
Complete Communicate using Markdown

Week 2-3: Intermediate Skills

Work through 2-3 intermediate courses based on your interests
Start contributing to open source projects (even small contributions count!)
Practice what you learn by building a personal project

Week 4+: AI-Powered Development

Sign up for GitHub Copilot (free trial available for individuals)
Complete Code with GitHub Copilot
Apply Copilot to your daily coding tasks
Explore advanced GitHub Actions and automation courses

Long-term: Certification Preparation

Review GitHub's certification offerings
Study recommended materials and complete relevant Skills courses
Join GitHub community discussions and forums
Schedule and take your certification exams

Tips for Maximising Your Learning

Here are some battle-tested strategies to get the most out of GitHub Skills:

Set a Schedule: Dedicate specific times each week to learning. Consistency beats intensity.
Build Projects: Apply what you learn immediately by building real projects.
Join Communities: Connect with other learners on GitHub Discussions, Discord, or Reddit.
Teach Others: The best way to solidify your knowledge is to explain it to someone else.
Don't Rush: Take time to understand concepts deeply rather than racing through courses.
Experiment Freely: GitHub Skills courses are in isolated repositories. Feel free to experiment without fear of breaking anything.

Microsoft Learn: 185+ GitHub Training Modules

Complement your GitHub Skills journey with Microsoft Learn, which offers over 185 GitHub-related training modules! Highlights include:

Recommended Learning Paths:

GitHub Copilot Fundamentals Part 1 (5 hr 11 min) - Comprehensive foundation
GitHub Copilot Fundamentals Part 2 (3 hr 19 min) - Advanced concepts

Language-Specific Copilot Courses:

Using GitHub Copilot with Python (22 min)
Using GitHub Copilot with JavaScript (22 min)

Advanced Topics:

Building applications with GitHub Copilot agent mode (50 min)
Introduction to prompt engineering with GitHub Copilot (30 min)
Responsible AI with GitHub Copilot (15 min)
Develop unit tests using GitHub Copilot tools (1 hr 7 min)

Additional Resources and Next Steps

Once you've completed the core GitHub Skills courses, continue your learning journey with these resources:

GitHub Docs: The comprehensive official documentation
GitHub Blog: Stay updated on new features and best practices
GitHub Community: Connect with other developers, ask questions, and share knowledge
GitHub Copilot Documentation: Deep dive into AI-assisted development
GitHub Copilot Trust Center: Security, privacy, and responsible AI policies
Pluralsight GitHub Courses: Subscription-based in-depth training
LinkedIn Learning GitHub Courses: Professional development resources
GitHub Copilot Bootcamp: Free hands-on training curriculum for mastering GitHub Copilot
GitHub Education Community Discussions: Connect with fellow learners

Conclusion: Your Journey Starts Now

The future of development is AI-powered, collaborative, and more accessible than ever before. With 44+ courses on GitHub Skills, 185+ modules on Microsoft Learn, five professional certifications, and a free tier of GitHub Copilot available to everyone, there has never been a better time to start your learning journey.

GitHub Skills provides you with a clear, structured path from complete beginner to certified expert in modern development practices. And remember, you're not alone on this journey. Join a community of:

100+ million developers on GitHub
5+ million students in GitHub Education
200K+ verified educators sharing knowledge

Your Action Checklist:

Start small: Don't try to learn everything at once
Practice consistently: Regular practice beats occasional cramming
Apply your knowledge: Build real projects to solidify your learning
Consider certification: Validate your skills with recognised credentials
Stay curious: The tech landscape evolves rapidly, commit to continuous learning
Join the community: Connect with fellow learners and share your progress

Whether you're aiming to land your first developer job, transition to a new role, or simply enhance your existing skills with AI-powered tools, GitHub Skills is your launchpad. The platform is free, the content is excellent, and the potential is limitless.

Ready to begin? Head over to skills.github.com and start your first course today. Your future self will thank you!

"Learning should be fun: There are no simulations or boring tutorials here, just hands-on lessons created by GitHub and taught with GitHub Actions."

Author

Marcel.LFollow

Microsoft MVP in DevTech - DevOps | DevOps Architect | Technical speaker focused on Microsoft technologies, Agentic AI, IaC & automation in Azure. Find me on GitHub: https://github.com/Pwd9000-ML

Like, share, follow me on: 🐙 GitHub | 🐧 X | 👾 LinkedIn

Date: 23-01-2026

Microsoft Ignite 2025 for Devs & DevOps: My Top Announcements

Marcel.L — Wed, 19 Nov 2025 17:20:05 +0000

Microsoft Ignite 2025 for Devs & DevOps: My Top Announcements

This years Microsoft Ignite 2025 is very clearly the "agentic AI" edition. The Book of News is packed with updates about agents, MCP, Copilots and end-to-end lifecycle tooling.

If you live in the world of GitHub, Azure, IaC and DevOps, there's a lot to unpack, but you don't need every announcement to understand how your day-to-day work is about to change.

In this post I'm focusing on the pieces that matter most for:

Developers shipping cloud apps on Azure
DevOps / SRE teams running infra at scale
Teams doubling down on GitHub & GitHub Copilot

Here's the quick hit list of the top announcements for this crowd:

Microsoft Foundry as the agentic developer platform, with a unified MCP tool catalogue.
Foundry Agent Service as a hosted, multi agent runtime with built-in memory and integration with Microsoft 365 and Agent 365.
Foundry Control Plane to operate agents with enterprise grade observability, governance and security.
The next phase of Azure Copilot embedded across portal, PowerShell and CLI for deployment, migration, optimisation and troubleshooting workflows.
Native integration between Microsoft Defender for Cloud and GitHub Advanced Security for runtime aware DevSecOps.
Azure DocumentDB (GA), SQL Server 2025 (GA) with GitHub Copilot integration, Azure HorizonDB (PostgreSQL, preview) and Fabric databases (GA) as an AI ready data layer.

Why It Matters

Three big themes jump out for engineering teams:

Agentic dev platforms are now real products, not slideware.

Microsoft Foundry + Foundry Agent Service + Azure Copilot form a stack for building and running AI agents with real governance, observability and runtime guarantees.
The data layer has gone fully "AI ready" for builders.

You get an open Azure DocumentDB service, an AI powered SQL Server 2025, a new Azure HorizonDB (PostgreSQL) for vector workloads and Fabric databases as a unified SaaS database experience.
Security and GitHub are stitched directly into the pipeline.

Microsoft Defender for Cloud now natively integrates with GitHub Advanced Security, connecting code → build → runtime and even using Copilot Autofix/GitHub Copilot to propose fixes.

Taken together, this is a pretty major reshape of the Dev/DevOps toolchain: agents and Copilots become first class participants in your pipelines, while GitHub sits at the center of secure SDLC.

Key Concepts or Pillars

Here are the core building blocks from Ignite that I'd highlight for any Dev/DevOps team.

1. Microsoft Foundry: the agentic developer platform

Microsoft Foundry is Microsoft's "factory" for AI apps and agents, and Ignite 2025 upgrades it significantly:

Unified MCP tool catalogue (preview). Developers get a single, governed catalogue of Model Context Protocol (MCP) tools – public and private – discoverable and managed from one secure interface in Foundry.
Deep business integration via Logic Apps. Connectors to 1,400+ systems (SAP, Salesforce, HubSpot, etc.) are exposed as MCP tools, so agents can act on real enterprise data and workflows without custom plumbing.
Prebuilt AI services as MCP servers. Transcription, translation, voice, document processing and more ship as ready made tools.
Custom tool extensibility. You can securely expose any API or function via API Management as MCP tools – perfect for wrapping existing line of business logic.

On top of that, the model router in Microsoft Foundry is now GA and can auto select from a pool of models (GPT-4.1, GPT-5, DeepSeek, Llama, Grok, etc.), optimising for cost, latency and quality, with reported up to 40% faster responses and 50% lower costs in early use.

For developers, this means:

"Pick the tools and guardrails, not the specific model per prompt."

2. Foundry Agent Service: hosted, multi agent runtime

Foundry Agent Service is evolving into an agent native runtime that hides a lot of "yak shaving" for infra and orchestration. New in preview:

Hosted agents: Deploy agents built with Microsoft Agent Framework, LangGraph, CrewAI or OpenAI Agents SDK without managing containers or infra.
Built-in memory: Agents get persistent, secure memory across sessions for context, preferences and history.
Multi agent workflows: Coordinate multiple specialised agents across long running processes (onboarding, approvals, supply chain, etc.) with either a visual designer or an API.
Microsoft 365 + Agent 365 integration: Deploy agents directly into Microsoft 365 apps via Agent 365, with governance and enterprise deployment patterns baked in.

The new Microsoft Agent Framework unifies previous work like Semantic Kernel + AutoGen into a single open-source SDK, with durable execution for more resilient agents.

This is very relevant for DevOps: it's basically "Kubernetes for agents" – but managed for you.

3. Foundry Control Plane: DevOps for agents

Foundry Control Plane (preview) extends Agent 365 so developers get visibility, security and control over agents running in the Microsoft Cloud.

Key ideas:

One place to see health, performance, usage and cost for agents.
Behavioural guardrails and policies applied centrally.
Built on Entra Agent ID, with Defender watching runtime activity and Purview protecting data flows.

If you currently treat microservices as deployable units, expect to treat agents as another fleet you observe, budget and secure.

Deep Dive: Azure Copilot + GitHub in the DevOps Loop

For infrastructure and app modernisation, the next phase of Azure Copilot is a big deal.

Azure Copilot now:

Lives directly inside the Azure portal, PowerShell and CLI as specialised agents (private preview).
Evolves chat into a full screen command centre, powered by GPT-5 reasoning, ARM-driven scenarios and artifact generation.
Respects existing RBAC, Azure Policy and compliance and requires explicit confirmation before changing resources.

Agent capabilities are very DevOps flavoured:

Deployment: Generate architectures and deployments aligned with the Well Architected Framework.
Migration: Discover workloads and generate AI powered IaaS/PaaS recommendations, with GitHub Copilot integration to help modernise .NET and Java apps and turn inventory into actionable code blueprints.
Optimisation: Surface cost + carbon aware actions and walk you through execution.
Observability & troubleshooting: Combine metrics, traces and logs (Azure Monitor / Application Insights) to diagnose fullstack issues and suggest mitigation, auto create support tickets when needed.

This effectively wires GitHub Copilot ↔ Azure Copilot ↔ ARM into a loop:

GitHub Copilot helps you define and refactor app + infra code.
Azure Copilot proposes target architectures, migration plans and optimisations.
Microsoft Foundry / Agent 365 manage agents and automations that keep that environment continuously modernised.

GitHub & Security: DevSecOps from Code to Runtime

The most GitHub specific security announcement is:

Native integration of Defender for Cloud + GitHub Advanced Security (preview)

Microsoft Defender for Cloud now natively integrates with GitHub Advanced Security to protect cloud native apps across the full app lifecycle, from code to runtime.

Highlights:

Runtime context + code linkage. Runtime threats are mapped back to the exact code in GitHub, helping teams prioritise exploitable issues rather than just noisy findings.
Real time collaboration. Security teams can create campaigns that notify GitHub repo owners, open GitHub issues directly from Defender, and track remediation status without leaving the security portal.
AI assisted fixes (Copilot Autofix + GitHub Copilot coding agent). The integration can generate suggested fixes with Copilot, reducing mean-time-to-remediate while keeping developers in familiar GitHub workflows.

For DevOps teams, this is basically DevSecOps with runtime awareness: CI/CD, repos, and runtime all feed a single security picture.

The Data Layer: AI Ready Databases for Builders

Ignite also brings several important updates to the data platform that directly impact developers.

Azure DocumentDB (GA)

First managed service built on the opensource DocumentDB standard under the Linux Foundation, compatible with MongoDB.
Multicloud ready, AI friendly with vector + hybrid search, instant autoscale and independent compute/storage scaling.

SQL Server 2025 (GA) – with GitHub Copilot integration

Access to AI models on-prem or in the cloud.
Native JSON support, REST APIs, and change event streaming.
Near real time analytics via mirroring data into Microsoft OneLake/Fabric.
GitHub Copilot integration in VS Code and SQL Server Management Studio 22, plus a new cross platform Python driver (mssql-python).

Azure HorizonDB (PostgreSQL, private preview)

Azure HorizonDB is a new PostgreSQL cloud database optimised for mission critical and AI workloads:

Fabric Databases (GA)

Fabric databases merge SQL DB + Cosmos DB into a unified SaaS database in Fabric with native vector and RAG support for real time, intelligent apps.

GitHub Copilot in the Wider Stack

Dataverse MCP Server (GA) + SDK for Python (preview).
Azure Copilot migration workflows.

The pattern is clear: GitHub Copilot becomes the coding surface, while Microsoft Foundry, Azure Copilot and Dataverse MCP provide the context and tools around it.

Additional Insight: How This Changes a Real DevOps Workflow

Imagine a fairly typical scenario:

You have a fleet of legacy .NET apps, some SQL Server workloads and a growing list of "let's build an agent for this" asks from the business.

Assess & plan with Azure Copilot.
Refactor with GitHub Copilot + App Service Managed Instance.
Modernise data with SQL Server 2025 / Azure HorizonDB / Fabric.
Introduce agents with Foundry Agent Service.
Secure the pipeline with Defender + GitHub.
Operate agents with Foundry Control Plane + Azure Copilot.

Practical Steps or How-To

If you want to start this month, here's a pragmatic checklist:

Get hands-on with Foundry Agent Service (where available).
Enable GitHub Advanced Security + Defender integration in a pilot repo.
Trial Azure Copilot in your infra lifecycle.
Pick one data workload to modernise.

Tips, Tricks, or Best Practices

Design for MCP from day one.
Treat agents as production workloads, not "experiments".
Keep GitHub as the single source of truth.
Start with one or two golden paths.

Conclusion

Microsoft Ignite 2025 signals a major step forward for developers and DevOps teams building on Azure and GitHub. The rise of agentic platforms, AI ready data services, and integrated DevSecOps workflows means that teams can deliver more intelligent, secure, and efficient applications than ever before.

Agent platforms (Microsoft Foundry, Foundry Agent Service, Agent 365)
AI-ready infra and data (Azure Copilot, Azure DocumentDB, SQL Server 2025, Azure HorizonDB, Fabric databases)
A tighter GitHub centric DevSecOps loop (Defender + GitHub Advanced Security + Copilot)

Embracing these tools and concepts will be key to staying competitive in the rapidly evolving landscape of cloud development and operations.

Author

Marcel.LFollow

Microsoft MVP in DevTech - DevOps | DevOps Architect | Technical speaker focused on Microsoft technologies, Agentic AI, IaC & automation in Azure. Find me on GitHub: https://github.com/Pwd9000-ML

Like, share, follow me on:

🐙 GitHub | 🐧 X | 👾 LinkedIn

Date: 19-11-2025

Automate Terraform Module Releases on the public registry using GitHub Actions

Marcel.L — Thu, 13 Nov 2025 17:11:59 +0000

Overview

This tutorial uses examples from the following GitHub project Terraform module repository - Dynamic Subnets.

If you enjoy creating public terraform modules for the community like I do, and host them on the public terraform registry. You will enjoy todays tutorial. We will be covering how you can automate and maintain your terraform module versioning using GitHub dependabot and also automate your module releases and pushing versioned releases to the public Terraform registry using GitHub Actions.

Getting started

Anyone can publish and share modules on the Terraform Registry for free. In this tutorial I wont be going into detail on how to create your account, linking it with your GitHub repository and doing the initial push to the registry.

This initial process is fairly well documented on HashiCorps tutorial on: How to publish modules to the registry. It is a fairly easy and frictionless process.

In this tutorial we are going to focus more on maintaining an existing module and how to automate releasing new versions using GitHub Actions. We will also look at how we can automatically update the provider versions (dependencies) used inside of the terraform module using a great feature of GitHub called Dependabot.

Enable Dependabot

Dependabot is a service built into GitHub that helps you update your dependencies automatically, so you can spend less time updating dependencies and more time building. Dependabot even includes checks for version updates for terraform providers inside of your configuration files which we will look at today.

Check out this list of package-ecosystems that's supported.

One key benefit is that dependency updates might contain security vulnerability fixes, bug fixes etc and manually keeping track of updates or updating them when a newer version is available is a lot of hassle. This is where Dependabot can help by automatically raising a Pull Request whenever there is a newer version of a dependency.

In my Terraform module repository - Dynamic Subnets, I have a terraform file called versions.tf:

terraform {
  required_version = ">= 1.0"
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = ">= 3.0"
    }
  }
}

NOTE: Using >= constraints allows more flexibility for module consumers while ensuring minimum version requirements are met.

We will set up dependabot by creating a special folder at the root of the repository called .github and inside that folder create a YAML file called dependabot.yml:

# To get started with Dependabot version updates, you'll need to specify which
# package ecosystems to update and where the package manifests are located.
# Please see the documentation for all configuration options:
# https://docs.github.com/en/code-security/dependabot/working-with-dependabot/dependabot-options-reference

version: 2
updates:
  - package-ecosystem: 'terraform' # See documentation for possible values
    directory: '/' # Location of package manifests
    schedule:
      interval: 'daily'
    # Optional: Limit number of open PRs for version updates
    open-pull-requests-limit: 5
    # Optional: Add labels to PRs
    labels:
      - 'dependencies'
      - 'terraform'
    # Optional: Add reviewers
    reviewers:
      - 'pwd9000'
    # Optional: Add assignees
    assignees:
      - 'pwd9000'
    # Optional: Customise commit message prefix
    commit-message:
      prefix: 'chore'
      include: 'scope'

Once the dependabot YAML file has been created and committed to the repository, you will notice that it automatically opened a Pull-Request for me, showing me that my provider version is out of date:

Now we can decide whether we want to accept this version bump or not by either accepting and merging the pull request or cancelling and closing the pull request. As you can also see the schedule interval is set to daily which means dependabot will check everyday to see if there are any new terraform provider versions released and automatically open a pull request if there is. Pretty neat!

Automate Releases - Terraform Registry

Say for example we take this version change (or any changes and improvements on our module), and after testing the changes on our module we want to create a new public release version of our module on the public Terraform Registry.

NOTE: I have written a public GitHub marketplace Action called: Terraform Tests for AZURE to do automated tests. Check it out.

After testing to perform a release we will create a workflow.

Security Note: It's recommended to use minimal permissions for GitHub Actions workflows. We'll add explicit permissions to our workflow.

Under the .github directory we will create a new folder called workflows and in this folder we will create another YAML file called: push-tf-registry.yml.

### This workflow can be used to manually create new release versions from a tag push using e.g. VSCODE ###
name: Release to terraform public registry

on:
  push:
    tags:
      - 'v*.*.*' # More specific pattern for semantic versioning

permissions:
  contents: write # Required for creating releases

jobs:
  Release:
    name: Release
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4.2.2 # Updated to latest version
      - uses: ncipollo/release-action@v1.14.0 # Updated to latest version
        with:
          generateReleaseNotes: true
          name: 'v${{ github.ref_name }}'
          token: ${{ secrets.GITHUB_TOKEN }}

This workflow will trigger on a tag push and create a GitHub Release. As per the documented process for creating a new release on the public terraform registry we have to use a valid semantic version, optionally prefixed with a v.

Example of valid tags are: v1.0.1 and 0.9.4. To publish a new module, you must already have at least one tag created.

To release a new version, create and push a new tag with the proper format. The webhook will notify the registry of the new version and it will appear on the registry usually in less than a minute.

The current version of my public module is version = 1.0.3:

This corresponds with the current release on the GitHub repository hosting the module:

With the GitHub workflow set up, Let's create a new tag and push that to our repository on GitHub. The workflow will trigger and create a new release for us automatically, so let's try it out.

After creating the tag 1.0.4 and pushing the tag to the remote repository. Notice that the workflow has triggered and ran, creating a new release automatically using the tag version number:

NOTE: The GitHub Action that creates the release has an input setting: generateReleaseNotes: true, so the release notes have also been created for us dynamically.

As you can see the new version is also now published on the Terraform Registry

That's it, now we can automatically let Dependabot take care of our terraform provider versioning and create pull requests automatically when new provider versions are released.

Additionally we also have a really straight forward easy way to create new releases of our own module by simply creating a valid semantic version number as a tag and then push that tag to our remote repository where the GitHub Workflow will create a release for us based on the semantic version tag.

As an added bonus, I also added another section onto the Dependabot config file to also regularly check the GitHub Actions used in the workflow called: ncipollo/release-action@v1 and actions/checkout@v4 so when new versions of these actions come out, Dependabot will also let me know that I can update my workflow actions (I've also changed my Dependency scans to run on a specific weekday and time as shown below).

version: 2
updates:
  - package-ecosystem: 'terraform'
    directory: '/' # Location of package manifests
    schedule:
      interval: 'weekly'
      day: 'sunday'
      time: '09:00'
      timezone: 'Europe/London'
    open-pull-requests-limit: 5
    labels:
      - 'dependencies'
      - 'terraform'
    reviewers:
      - 'pwd9000'
    assignees:
      - 'pwd9000'
    commit-message:
      prefix: 'chore'
      prefix-development: 'fix'
      include: 'scope'
    # Optional: Ignore specific versions or version ranges
    ignore:
      - dependency-name: 'hashicorp/azurerm'
        versions: ['2.x', '3.0.0']
    # Optional: Allow specific dependency updates
    allow:
      - dependency-type: 'all'
    # Optional: Target branch for PRs (default is the default branch)
    target-branch: 'main'
    # Optional: Milestone to set on PRs
    milestone: 1
    # Optional: Prefix for PR branch names
    pull-request-branch-name:
      separator: '-'

  - package-ecosystem: 'github-actions'
    # Workflow files stored in the
    # default location of `.github/workflows`
    directory: '/' # Location of package manifests
    schedule:
      interval: 'weekly'
      day: 'friday'
      time: '09:00'
      timezone: 'Europe/London'
    open-pull-requests-limit: 5
    labels:
      - 'dependencies'
      - 'github-actions'
    # Optional: Group updates together
    groups:
      github-actions:
        patterns:
          - 'actions/*'
        update-types:
          - 'minor'
          - 'patch'

Advanced Dependabot Configuration

For more complex scenarios, you can leverage additional Dependabot features:

Grouping Dependencies

Starting with Dependabot version 2, you can group related updates together:

groups:
  terraform-providers:
    patterns:
      - 'hashicorp/*'
      - 'azure/*'
    update-types:
      - 'minor'
      - 'patch'

Vendor or Cache Dependencies

For ecosystems that support it, you can specify vendoring:

vendor: true # For ecosystems like Go

Rebase Strategy

Control how Dependabot handles rebasing:

rebase-strategy: 'auto' # Options: auto, disabled

Versioning Strategy

Specify how to update manifest files:

versioning-strategy: 'increase' # Options: auto, increase, increase-if-necessary, lockfile-only, widen

Security Updates Configuration

Enable or disable security updates:

enable-beta-ecosystems: true # For beta ecosystem support
insecure-external-code-execution: 'deny' # Options: allow, deny

Custom Registry Configuration

For private registries or custom sources:

registries:
  - terraform-private:
      type: 'terraform-registry'
      url: 'https://my-private-registry.com'
      token: '${{secrets.REGISTRY_TOKEN}}'

Note: When using custom registries, ensure the token is properly configured in your repository secrets.

These additional options provide fine-grained control over how Dependabot manages your dependencies, allowing you to customise the automation to fit your team's workflow perfectly.

Troubleshooting Common Issues

Module Not Appearing on Terraform Registry

Ensure your repository name follows the format: terraform-<PROVIDER>-<NAME>
Verify the webhook is properly configured in your GitHub repository settings
Check that your tags follow semantic versioning (e.g., v1.0.0, 1.0.0)

Dependabot PRs Not Being Created

Verify the .github/dependabot.yml file is in the default branch
Check repository settings to ensure Dependabot is enabled
Review the Dependabot logs in the repository's Insights > Dependency graph > Dependabot

Release Workflow Failures

Ensure the GITHUB_TOKEN has appropriate permissions
Verify tag format matches the workflow trigger pattern
Check that previous releases don't have conflicting names

Best Practices

Version Constraints: Use flexible version constraints (>=) in modules to avoid forcing specific versions on consumers
Testing: Always test module changes before creating a new release
Documentation: Keep your README and examples updated with each release
Security: Regularly review and merge Dependabot security updates
Semantic Versioning: Follow semantic versioning strictly:
- MAJOR version for incompatible API changes
- MINOR version for backwards-compatible functionality additions
- PATCH version for backwards-compatible bug fixes

Fully Automated Testing and Release on changes to IaC

Check out the next blog post on this series: Using Terraform on GitHub that shows how to perform fully automated integration test when Dependabot opens a PR. Followed by automatically merging that pull request if all tests have finished successfully and then also as a last step automatically deploy a new release/version and pushing that to the Terraform registry: Automated Terraform Tests for Azure using GitHub Actions

I hope you have enjoyed this post and have learned something new. You can find the code samples used in this blog post on my GitHub project Terraform module repository - Dynamic Subnets. ❤️

If you are interested in checking out my public terraform modules for azure, including some cool modules like OpenAI-Service, OpenAI-Private-ChatGpt, Custom Role Definitions and Sonarqube ACI, you can find them on the public terraform registry:

Pwd9000-ML - Public Terraform Registry Modules

Author

Like, share, follow me on: 🐙 GitHub | 🐧 X | 👾 LinkedIn

Marcel.LFollow

Microsoft MVP in DevTech - DevOps | DevOps Architect | Technical speaker focused on Microsoft technologies, Agentic AI, IaC & automation in Azure. Find me on GitHub: https://github.com/Pwd9000-ML

Managing GitHub Copilot & VS Code Settings Across Teams

Marcel.L — Wed, 12 Nov 2025 16:49:29 +0000

Managing GitHub Copilot & VS Code Settings Across Teams

Ensuring consistent development environments across your team is crucial for productivity and code quality. This guide explores five practical approaches to manage VS Code settings and GitHub Copilot configurations: workspace configurations, VS Code profiles, bootstrap scripts, enterprise policies, and a combined strategy that leverages the strengths of each method. For a detailed, complementary walkthrough of every GitHub Copilot and Copilot Chat setting that can be configured in VS Code, see the companion article: Tune GitHub Copilot Settings in VS Code.

1) Repository Workspace Settings (`.vscode/settings.json`)

The simplest and most widely adopted approach is to commit VS Code workspace configuration files directly to your repository. These workspace settings override user preferences when the project folder is open.

Implementation

Create a .vscode/ directory in your repository root with these configuration files:

.vscode/settings.json - Project-specific settings:

{
  "editor.formatOnSave": true,
  "editor.defaultFormatter": "esbenp.prettier-vscode",
  "editor.tabSize": 2,
  "files.eol": "\n",
  "files.trimTrailingWhitespace": true,
  "typescript.preferences.quoteStyle": "single",

  // GitHub Copilot settings
  "github.copilot.enable": {
    "*": true,
    "plaintext": false,
    "markdown": true,
    "scminput": false
  }
}

.vscode/extensions.json - Recommended extensions:

{
  "recommendations": [
    "github.copilot",
    "github.copilot-chat",
    "dbaeumer.vscode-eslint",
    "esbenp.prettier-vscode",
    "ms-vscode.vscode-typescript-next"
  ],
  "unwantedRecommendations": []
}

Pros:

Version controlled with code
Zero configuration for developers
Project-specific conventions
Works across all platforms

Cons:

Not enforced (users can override)
Limited to workspace scope
No control over user-level settings

Best for: All collaborative projects as a baseline configuration.

2) VS Code Profiles (Team Configuration Templates)

VS Code Profiles bundle settings, extensions, UI layout, and keybindings into shareable configurations. Teams can maintain standard profiles for different roles or tech stacks.

Creating and Sharing Profiles

Configure VS Code with desired settings and extensions
Open Command Palette → "Profiles: Export Profile..."
Choose what to include (settings, extensions, UI state, keybindings, snippets, tasks)
Export as .code-profile file (profile export documentation)
Share via repository, wiki, or internal documentation

Tip: If you're using VS Code Profiles to standardise settings across teams, the companion article Tune GitHub Copilot Settings in VS Code includes a detailed sample settings.json and explains Copilot-specific keys you might want to include.

Importing a Profile

New team members can import profiles via:

Command Palette → "Profiles: Import Profile..."
Or via URL if hosted: code --profile "Team Profile" --profile-import-url https://example.com/profile.code-profile

Pros:

Complete environment replication
Includes UI layout and theme
Multiple profiles for different contexts
Built-in VS Code feature

Cons:

Manual import required
No automatic updates
Can diverge over time

Best for: Onboarding new developers, standardising team environments.

3) Enterprise Management Policies

For organisations requiring strict compliance, VS Code supports policy management through various enterprise tools.

Windows Group Policy / Intune Configuration

VS Code respects policies set via:

Windows Registry (Group Policy)
macOS preferences
Linux policy files

Example policy locations:

Windows: HKLM\SOFTWARE\Policies\Microsoft\VSCode
macOS: /Library/Preferences/com.microsoft.VSCode.plist
Linux: /etc/vscode/policies.json

Supported Policy Settings

Learn more about available policy settings:

{
  "UpdateMode": "manual",
  "TelemetryLevel": "off",
  "ExtensionsGallery": {
    "serviceUrl": "https://internal-marketplace.company.com"
  },
  "ExtensionsAllowedList": [
    "github.copilot",
    "github.copilot-chat",
    "ms-vscode.vscode-typescript-next"
  ],
  "GitHubCopilotSettings": {
    "enabled": true,
    "organizationAccess": "allowed"
  }
}

Pros:

Centrally enforced
Audit compliance
Cannot be overridden by users

Cons:

Requires IT infrastructure
Platform-specific implementation
Less flexible for developers

Best for: Regulated industries, security-sensitive environments.

4) Bootstrap Scripts (Automated Setup)

Scripts can automate the configuration of VS Code settings, especially useful for ephemeral environments like GitHub Codespaces or CI runners.

Cross-Platform Setup Script

PowerShell (Windows/PowerShell Core):

# scripts/setup-vscode.ps1
param(
    [switch]$Force
)

$repoSettings = Join-Path $PSScriptRoot '../.vscode/settings.json'
$userSettingsDir = if ($IsLinux -or $IsMacOS) {
    "$HOME/.config/Code/User"
} else {
    "$env:APPDATA/Code/User"
}
$userSettings = Join-Path $userSettingsDir 'settings.json'

if (!(Test-Path $repoSettings)) {
    Write-Warning "Repository settings not found at: $repoSettings"
    exit 1
}

# Ensure directory exists
New-Item -ItemType Directory -Force -Path $userSettingsDir | Out-Null

# Merge or copy settings
if ((Test-Path $userSettings) -and !$Force) {
    Write-Host "Merging settings..."
    $current = Get-Content $userSettings -Raw | ConvertFrom-Json
    $new = Get-Content $repoSettings -Raw | ConvertFrom-Json

    foreach ($prop in $new.PSObject.Properties) {
        $current | Add-Member -MemberType NoteProperty -Name $prop.Name -Value $prop.Value -Force
    }

    $current | ConvertTo-Json -Depth 10 | Set-Content $userSettings
} else {
    Write-Host "Copying settings..."
    Copy-Item $repoSettings $userSettings -Force
}

Write-Host "✓ VS Code settings configured" -ForegroundColor Green

Bash (Linux/macOS):

#!/usr/bin/env bash
# scripts/setup-vscode.sh
set -euo pipefail

REPO_SETTINGS="$(dirname "$0")/../.vscode/settings.json"
USER_SETTINGS_DIR="${HOME}/.config/Code/User"
USER_SETTINGS="${USER_SETTINGS_DIR}/settings.json"

if [[ ! -f "$REPO_SETTINGS" ]]; then
    echo "Repository settings not found at: $REPO_SETTINGS" >&2
    exit 1
fi

# Ensure directory exists
mkdir -p "$USER_SETTINGS_DIR"

# Merge or copy settings
if [[ -f "$USER_SETTINGS" ]] && [[ "${1:-}" != "--force" ]]; then
    echo "Merging settings..."
    # Using jq for JSON merging
    jq -s '.[0] * .[1]' "$USER_SETTINGS" "$REPO_SETTINGS" > "${USER_SETTINGS}.tmp"
    mv "${USER_SETTINGS}.tmp" "$USER_SETTINGS"
else
    echo "Copying settings..."
    cp "$REPO_SETTINGS" "$USER_SETTINGS"
fi

echo "✓ VS Code settings configured"

Best for: CI/CD pipelines, development containers, Codespaces.

5) Recommended Combined Strategy

Layer these approaches based on your organisation's needs:

Small Teams / Open Source Projects

Primary: .vscode/settings.json and .vscode/extensions.json
Optional: Shared profile for complex setups

Medium Sized Teams

Foundation: Repository workspace settings
Onboarding: Team VS Code profile
Automation: Bootstrap script for Codespaces/containers

Enterprise Organisations

Baseline: Repository workspace settings
Standards: Department/role-based VS Code profiles
Compliance: Enterprise policies via MDM
Automation: Bootstrap scripts for cloud workstations

GitHub Copilot-Specific Configuration

Key Settings and Their Impact

Learn more about GitHub Copilot settings in VS Code:

Setting	Scope	Purpose
`github.copilot.enable`	Workspace/User	Control Copilot per language
`github.copilot.advanced.authProvider`	User	Authentication method
`github.copilot.editor.enableAutoCompletions`	User/Workspace	Automatic suggestions
`github.copilot.chat.localeOverride`	User	Chat interface language

For a full list and explanation of Copilot-related VS Code settings (including chat, agent, and inline suggestion keys) check: Tune GitHub Copilot Settings in VS Code.

Security Considerations

Review GitHub Copilot security best practices:

{
  // Disable Copilot for sensitive files
  "github.copilot.enable": {
    "*": true,
    "plaintext": false,
    "markdown": true,
    "env": false,
    "dotenv": false,
    "yaml": false
  }
}

Troubleshooting Common Issues

Issue	Cause	Solution
Settings not applying	Policy override	Check enterprise policies with `code --status`
Copilot not working	License/auth issue	Verify with `GitHub Copilot: Check Status` command (troubleshooting guide)
Extensions missing	Marketplace access	Confirm network/proxy settings
Profile not importing	Version mismatch	Update VS Code to latest version

Best Practices

Start simple: Begin with repository settings before adding complexity
Document changes: Maintain a CHANGELOG for settings updates
Test incrementally: Validate settings in a clean environment
Respect autonomy: Balance standardisation with developer flexibility
Regular reviews: Audit settings quarterly for relevance

Conclusion

Effective settings management improves team velocity and code consistency. Start with repository-level configuration files as they provide immediate value with minimal overhead. Add VS Code profiles for richer onboarding experiences, and only implement enterprise policies when compliance demands it. The layered approach ensures you can adapt as your team grows without sacrificing developer productivity.

Author

Marcel.LFollow

Microsoft MVP in DevTech - DevOps | DevOps Architect | Technical speaker focused on Microsoft technologies, Agentic AI, IaC & automation in Azure. Find me on GitHub: https://github.com/Pwd9000-ML

Like, share, follow me on: 🐙 GitHub | 🐧 X | 👾 LinkedIn

Date: 12-11-2025