The art of simplicity

In previous posts, I covered how to customize the GitHub Copilot CLI statusline. First with the default options , then with a dynamic script . Today we're taking it a step further: integrating Oh My Posh to bring full prompt theming support to your Copilot CLI session. Oh My Posh has native support for GitHub Copilot CLI, so you get all its theming power (Nerd Font icons, color gradients, diamond-style segments,…) rendering right inside the Copilot CLI statusline. What Is Oh My Posh? Oh My Posh is a cross-shell prompt engine that lets you define richly styled prompts using a JSON (or YAML/TOML) configuration file. You probably know it from PowerShell or bash, but it also ships a dedicated copilot subcommand specifically for integration with GitHub Copilot CLI's statusLine feature. Prerequisites Oh My Posh installed ( winget install JanDeDobbeleer.OhMyPosh   see docs ) A Nerd Font installed and set as your terminal font (for icons to render correctly) Gi...

While reviewing an ASP.NET Core Razor page application that needed to share server-side configuration with client-side JavaScript, I noticed the following approach to inject a JSON object: <script> var featureFlags= @Html.Raw(Model.FeatureFlagsJson); </script> It works — until it doesn't. This post walks through the right way to do it, why the naive approach can blow up in your face, and what the production-safe pattern looks like. Why the naive approach is dangerous Directly interpolating server-side values into a <script> block creates an XSS (Cross-Site Scripting) vector . If any value in your config object contains characters like </script> , " , or ' , the browser can interpret that as the end of your script tag — or worse, execute attacker-controlled code. Consider this innocent-looking config value: public string FeatureFlags{ get; set; } = "My App </script><script>alert('pwned')"; Inlined naiv...

This final post continues on the multi-agent path: instead of one agent doing more things, we compose multiple agents doing the right things. Yesterday I demonstrated how to do this inside the Copilot SDK itself, today we look the broader ecosystem and I’ll show you how to integrate your Copilot SDK agent in the Microsoft Agent Framework. Microsoft Agent Framework The Microsoft Agent Framework(MAF) is the unified successor to Semantic Kernel and AutoGen. It provides a standard interface for building, orchestrating, and deploying AI agents. Dedicated integration packages let you wrap a Copilot SDK client as a first-class MAF agent — interchangeable with any other agent provider in the framework. The key distinction from Part 1: custom agents inside the SDK work within a single Copilot session, with the Copilot runtime as orchestrator. MAF operates at a higher level — it can compose a Copilot SDK agent with agents backed by Azure OpenAI, Anthropic, or any other provider, using st...

We've covered a lot of ground in this series: sessions and lifecycle, deployment and scaling, MCP integration, and skills. Each post added a new capability layer to a single agent. This post changes the shape of the problem: instead of one agent doing more things, we compose multiple agents doing the right things. There are two different levels at which you can do this. Inside the Copilot SDK itself, custom agents let the Copilot runtime orchestrate specialised sub-agents automatically within a single session. Beyond the SDK, the Microsoft Agent Framework lets you compose Copilot SDK agents with agents from any other provider in structured multi-agent workflows. In this post we stay inside the SDK. Our next and final post will look at the broader ecosystem and Microsoft Agent Framework integration. The problem with a single agent A single session with a broad system prompt is fine for many use cases. But as tasks grow more complex, the cracks show: A general agent need...

Up to this point in the series, we've extended the agent's capabilities in two ways: custom C# tools that execute code, and MCP servers that connect to external systems. Both are about what the agent can do . Skills are about what the agent knows and more specifically, how to apply that knowledge in a repeatable, composable way. A skill is a folder containing a SKILL.md file with specialised instructions, and optionally supporting files like scripts, templates, or examples. You point the SDK at a directory, the agent scans for skills automatically, and when a task matches a skill's description, that skill's instructions are injected into the session context. The agent gains focused expertise — without you writing any C#, and without redeploying your application. Why skills exist Think about a development task you repeat across projects: scaffolding a solution, writing a particular kind of test, generating API documentation in a house style, following a specific ...

After a short break, I'm back with my series about the GitHub Copilot SDK. So far, we have covered: You don't need to build your own agent harness Getting started with the GitHub Copilot SDK in .NET Sessions in the GitHub Copilot SDK: What they are and how to manage them Deploying and scaling Authentication and observability Today, we cover MCP integration — connecting your agent to external context and services via the Model Context Protocol, so your agent can reach databases, APIs, and cloud services without you having to build the glue. The agent we've built so far knows how to reason and plan, and can call C# tools you define directly. But there's a whole ecosystem of pre-built capabilities out there. Servers that talk to Azure, GitHub, databases, Slack, internal systems — all speaking the same open standard. MCP is how your agent connects to that ecosystem. Instead of writing tool integrations from scratch, you point the SDK at an MCP serv...