Skip to main content

How to use GitHub Copilot Agent Skills in Visual Studio

With the introduction of agent skills, we can teach our AI agent to handle our most repetitive and specialized workflows. After adding context through an agent.md file, integrating tool calls using MCP, creating our own Agents, this is a logical next step in defining your AI enabled software development lifecycle.

Here's everything you need to know to get started.


What are agent skills?

Agent skills are folders of instructions, scripts, and resources that GitHub Copilot can load automatically when relevant to your prompt. Think of them as reusable "playbooks" you write once and invoke repeatedly — without having to re-explain the context every time.

Unlike custom instructions, which set broad coding guidelines that apply across nearly every task, skills are meant for specialized, on-demand capabilities: things like running a specific test suite, converting file formats, generating components, or following a custom deployment checklist.

How to create your first skill

Skills follow an open standard, which means they work across multiple AI tools and IDE’s.

Skills location

Skills live in a dedicated directory. You have two placement options:

Project-scoped skills (specific to one repository):

.github/skills/
.claude/skills/
.agents/skills/

Personal skills (shared across all your projects):

~/.copilot/skills/
~/.agents/skills/

Remark: Visual Studio 2026 discovers skills from all of these locations automatically.

Skill structure

Each skill is a folder containing at minimum a SKILL.md file. This file uses YAML frontmatter to describe the skill and a Markdown body to provide instructions.

Here's a minimal example — a skill that formats code comments according to your team's style:

.github/skills/
  comment-formatter/
    SKILL.md
    examples/
      before.js
      after.js

And the SKILL.md itself:

---
name: comment-formatter
description: Formats inline code comments to match our team's documentation style guide.
---

When asked to clean up or format comments in a file, follow these rules:

1. Use JSDoc-style block comments for all functions.
2. Write in present tense ("Returns the user object", not "Return...").
3. Keep lines under 80 characters.
4. Reference the examples in `examples/before.js` and `examples/after.js` to calibrate style.

Once your skill is in place, Copilot discovers it automatically. There are two ways to use it:

  • Let Copilot decide: When you type a relevant prompt like "clean up comments in this file," Copilot matches it against your skill's description and loads the skill automatically.
  • Invoke manually: Type /comment-formatter in the chat to trigger it directly. You can also add extra context: /comment-formatter for the auth module.

Using community skills

You don't have to write every skill from scratch. There are multiple great sources for pre-built skills:

You can install them using the GitHub CLI:

gh skill install <repo>/<skill-name>

or when using a skill from skills.sh:

npx skills add <owner/repo>

Always review a skill's contents before installing it, especially if it includes scripts with bash in allowed-tools.

Skills in Visual Studio 2026

If you're on Visual Studio 2026, Agent Skills were added in the March 2026 update. The experience is largely the same:

  1. Place your skills in .github/skills/, .claude/skills/, or .agents/skills/ in your repository.
  2. Visual Studio discovers them automatically.
  3. Skills appear in the Tools window alongside any installed MCP servers:


Once your skill is in place, Copilot discovers it automatically. From that moment on, the Copilot Agent can decide to use this skill when appropriate. When a skill is active, it appears in the chat so you know it's being applied.

I couldn’t find a way to manually invoke a skill, but I hope that is a feature that will be added in the future.

Wrapping up

Agent Skills represent a meaningful shift in how developers can work with GitHub Copilot. Rather than relying on a one-size-fits-all AI, you can now build a library of application specific capabilities that grow with your team and your codebase. Whether you're automating a deployment checklist, enforcing a documentation format, or wiring up a custom conversion pipeline, skills give you a structured, repeatable, and portable way to get there.

I'm happy to see that there are finding their way also in Visual Studio. So, no excuse to not use it!

My recommendation: start small.

Pick one repetitive task you do every week and write a skill for it. The investment is minimal, and the payoff compounds over time.

More information

Manage agent skills with GitHub CLI - GitHub Changelog

Use Agent Skills with GitHub Copilot - Visual Studio (Windows) | Microsoft Learn

How I built a custom agent skill to configure Application Insights



Popular posts from this blog

Podman– Command execution failed with exit code 125

After updating WSL on one of the developer machines, Podman failed to work. When we took a look through Podman Desktop, we noticed that Podman had stopped running and returned the following error message: Error: Command execution failed with exit code 125 Here are the steps we tried to fix the issue: We started by running podman info to get some extra details on what could be wrong: >podman info OS: windows/amd64 provider: wsl version: 5.3.1 Cannot connect to Podman. Please verify your connection to the Linux system using `podman system connection list`, or try `podman machine init` and `podman machine start` to manage a new Linux VM Error: unable to connect to Podman socket: failed to connect: dial tcp 127.0.0.1:2655: connectex: No connection could be made because the target machine actively refused it. That makes sense as the podman VM was not running. Let’s check the VM: >podman machine list NAME         ...

Cache stampede: when our cache turned against us

While investigating some performance issues, we ran into an ASP.NET Core API that cached a fairly expensive aggregation query for 60 seconds. Under normal load, that was fine: one request rebuilds the cache, everyone else reads from it. Under peak load, dozens of requests would arrive in that same expiry window, all see a cache miss, and all fire the same expensive query in parallel. The database didn't like that. That was the moment when our caching layer stopped helping and started hurting. A burst of requests comes in at the same time, all miss the cache, and all go hammer the database or the downstream API at once. That's a cache stampede . The cache was supposed to protect our backend, and for a few hundred milliseconds it did the opposite. Why this happens IMemoryCache.GetOrCreate (and its async sibling) looks like it protects you, but it doesn't add any locking on its own. Look at the naive version: public async Task<Report> GetReportAsync(string key) ...

A complex system designed from scratch never works

A few years ago, I worked as an architect on a big mainframe rewrite. I still count it as one of my failures. Not because the technology was wrong, but because I couldn't convince the management team to simplify the approach. Years later, the organization is still struggling to get the new system up and running. I left the project at the time, because I couldn't put my name behind an approach that would take very long and cost a lot of money without a working system to show for it along the way. Gall’s Law That memory keeps coming back to me, because it's a textbook case of Gall's Law playing out in real life. Gall's Law , from John Gall's Systemantics , states it plainly: A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works, and it cannot be patched to make it work. You have to start over with a simple system that works. What does that mean in practice,...