The art of simplicity

Note: this post is part of a series. Part one covered packaging a skill in a plugin for Claude Code . Same idea, different tool, this time focussing on GitHub Copilot. After writing that first post I got the obvious follow-up question: does this also work for GitHub Copilot? Short version: yes, SKILL.md itself is portable, but the plugin wrapper isn't. Copilot CLI has its own plugin format, laid out slightly differently from Claude Code's. What's the same? A skill is still just a folder with a SKILL.md inside: YAML frontmatter ( name , description , optionally license ), then a Markdown body with instructions. Copy that file as-is between tools — nothing about the skill content needs to change. What's different? Where Claude Code wants the manifest tucked inside .claude-plugin/plugin.json , Copilot CLI puts plugin.json straight at the plugin root: api-testing-plugin/ ├── plugin.json # Required manifest, at the root ├── agents/ #...

It didn't take long until skills became a key element in our agentic development workflow. At that moment a skill stopped being "that SKILL.md I keep in one project" and became something we want on every machine, for every teammate, without copy-pasting a folder around. That's the point where you package it into a plugin. A plugin is a container: it bundles one or more skills plus optionally commands, agents, hooks, and MCP servers into a single installable unit with a manifest. Skills are the "what to do", plugins are the "how you get it onto someone else's machine". Our first approach: using git submodules Our first approach was through centralizing all our skills in a separate Git repo and share it between projects by using git submodules. That approach worked but felt more like a hack than a final solution. The better approach: wrap it in a plugin A plugin is just a directory with a manifest and a conventional layout: my-plugin/...

Yesterday I was talking about git submodule support in Visual Studio and that reminded me of something else: Azure DevOps Server got submodule support too. It's a small feature, but a genuinely useful one. Why do we need this? If you've worked with submodules before, you know the annoying part isn't adding them, it's navigating them afterwards. In the Files hub, a submodule used to just show up as a folder reference. To actually browse its content, you had to know the submodule's repo, open it separately, and find the right commit yourself. What changed Azure DevOps Server now has UI support for Git submodules in the Files hub. You can click straight into a submodule from your project and land exactly on the commit that's referenced there. No more manually tracking down the right repo and commit by hand. It works across multiple Git services that a submodule can point to: Azure Repos GitHub GitLab Bitbucket Multiple .gitmodules URL...

Git submodules wasn't a feature I used that often. Until we started to use it as a way to share context( agent.md ) and skills between our projects. That's the moment we discovered that Git submodule support was missing in Visual Studio and we had to fall back to the terminal typing git submodule update --init --recursive With Visual Studio 18.9, that finally changes. Submodules are now a first-class part of the Git experience in the IDE. What was missing Submodules are genuinely useful. They let you pull a shared library, an SDK, or a set of build scripts into your repository without copy-pasting code around. You could fall back to the command line, but the tooling was missing. Visual Studio would show you a submodule as a plain folder, with no indication of its state, no way to add or remove one from the UI, and no understanding of how it related to the parent repository. Every actual submodule operation meant tabbing out to the command line. What you get now Open a...

After our fix yesterday, we got our Renovate pipeline up-and-running. However the next hurdle showed up quickly. Right after the SSL certificate fix, I got the pipeline green, but the log showed this warning: WARN: Azure: work item type does not exist in project (or the token lacks permission to it); skipping issue. The Dependency Dashboard needs a process that defines this work item type. Set one your project defines via the `azureWorkItemType` repo config option. (repository=Framework en Tooling/SOFACore) "workItemType": "Issue", "availableTypes": [ "Bug", "Task", "Quality of Service Requirement", "Scenario", "Risk", "Code Review Request", "Code Review Response", "Feedback Request", "Feedback Response", "User Story", "Test Case", ...

Recently I ran into a failing Renovate pipeline right after configuring it against our internal Azure DevOps server: "err": { "code": "UNABLE_TO_VERIFY_LEAF_SIGNATURE", "message": "unable to verify the first certificate; if the root CA is installed locally, try running Node.js with --use-system-ca" } Error: unable to verify the first certificate; if the root CA is installed locally, try running Node.js with --use-system-ca at TLSSocket.onConnectSecure (node:internal/tls/wrap:1748:34) at TLSSocket.emit (node:events:509:28) at TLSSocket.emit (node:domain:489:12) at TLSSocket._finishInit (node:internal/tls/wrap:1185:8) at TLSWrap.ssl.onhandshakedone (node:internal/tls/wrap:966:12) The root cause: Renovate runs on Node.js, and Node doesn't use the Windows certificate store by default. Our internal Azure DevOps server presents a certificate signed by our internal CA, and Node has no idea that CA exist...