Most Developers Are Still Using Copilot at the Shallow End
Most developers use GitHub Copilot like a faster autocomplete engine. Useful, yes — but still the shallow end of the pool.
The bigger opportunity is building domain-expert plugins: packages that give Copilot a clear identity, specialized knowledge, and real tools it can use on your behalf. That's when the experience changes from "I ask Copilot for help" to "I built a Copilot teammate that understands my world."
If you think in terms of VS Code extensions or chat participants, the mental model is similar: package context, behavior, and capability into a specialist that shows up with judgment built in.
Want the complete implementation? Subscribe to the newsletter →
A Copilot Plugin Is Identity + Knowledge + Actions
The pattern is simple once you see it. A strong plugin has three layers:
- Identity — what the plugin is, when it should activate, and what components it includes.
- Knowledge — reusable domain expertise encoded as skills.
- Actions — MCP-connected tools that let the plugin do work instead of just talk about it.
That combination is what turns a generic assistant into a specialist.
I've been using this pattern across production systems because it solves a real problem: you stop re-explaining the same domain context every session. Instead of reminding Copilot about your release process, video pipeline, or internal conventions over and over, you package that knowledge once and let the runtime load it when relevant.
plugin.json Is the Identity Card
Every plugin starts with plugin.json. GitHub's plugin docs are explicit: a Copilot CLI plugin must include a manifest at the root, and that manifest tells the runtime what this package is and where its pieces live.
That sounds small, but it's the architectural pivot.
plugin.json is the plugin's identity card. It declares the name, description, metadata, and the paths to things like skills and MCP configuration. In practice, that means your plugin stops being "some loose prompt files in a repo" and becomes a portable capability you can install, share, and evolve.
GitHub's own docs on creating Copilot CLI plugins show the expected structure clearly: a root manifest, optional agents/, optional skills/, optional hooks, and optional .mcp.json.
Skills Encode Human Expertise into Reusable Capability
The second layer is where the plugin gets smart.
A skill is a SKILL.md file with YAML frontmatter. GitHub's skills docs make two things clear: the frontmatter describes what the skill does and when to use it, and the body contains the actual instructions, examples, and guidance.
That's more important than it sounds.
A lot of teams still treat AI behavior as a giant blob of prompt text. Skills are better because they package expertise at the workflow level: release prep, video captioning rules, GitHub Actions review, whatever your domain needs.
That means domain knowledge becomes:
- Structured instead of scattered
- Reusable instead of copy-pasted
- Composable instead of monolithic
I wrote about this broader shift in Agent Skills: Microsoft Just Shipped What You've Been Building. The short version is simple: skills are how you scale judgment without turning your agent into a bloated mess.
And this isn't limited to one surface. GitHub's docs explicitly note that skills work with the Copilot cloud agent, Copilot CLI, and agent mode in VS Code. That's a big deal. You aren't building a one-off hack for one interface. You're building reusable capability for the Copilot runtime.
Newsletter subscribers get the real configs, code, and architecture files. The full issue includes the exact manifest patterns, production
SKILL.mdstructure, and the wiring that makes these plugins behave like specialists instead of glorified prompts. Get the deep dive →
MCP Gives Plugins Hands
Knowledge alone is not enough. A useful AI teammate needs the ability to act.
That's where Model Context Protocol changes the game. MCP gives plugins a structured way to expose tools the model can call: query APIs, inspect state, kick off workflows, fetch artifacts, or validate outputs.
This is the line between an assistant that says, "You should probably check the pipeline," and one that actually checks the pipeline, reads the result, and tells you what matters.
Once you combine:
- a manifest that establishes identity,
- skills that encode judgment, and
- MCP tools that expose actions,
...you stop building assistants that merely explain work. You start building teammates that participate in it.
If you want the broader architecture behind that jump, it's tightly connected to the patterns I broke down in GitHub Copilot CLI Extensions: The Complete Guide and The Three Layers Your AI Agent Is Missing.
Three Production Plugins That Prove the Pattern
This isn't hypothetical. The pattern already holds across three public repos:
1. htekdev/devops-copilot-skill
This one is the DevOps Workflow Orchestrator: repo health, release prep, workflow linting, dependency audit, and migration readiness. It shows what happens when Copilot starts understanding your operational workflow as a system.
2. htekdev/vidpipe-copilot-plugin
This plugin specializes in media production: video analysis, FFmpeg editing workflows, silence removal, captions, and multi-platform output generation. Same pattern, completely different domain. That's the point. Once the architecture is right, the domain can change and the shape still holds.
3. htekdev/copilot-plugin-skill
This is the meta move: a plugin for building plugins. It packages the conventions, templates, and hard-won lessons required to scaffold new Copilot capabilities faster. That repo is proof that once you figure out the pattern, you can teach Copilot to reproduce it.
Taken together, these three examples make the case clearly: the progression is not just "I use Copilot." It's "I build on Copilot."
Why This Matters More Than Another Prompt Trick
Prompt tricks are fragile. Domain architecture scales.
Plugins let you move important behavior out of ephemeral chat context and into versioned, inspectable files. Your team can review them, evolve them, reuse them, and ship them.
If you're serious about building agentic systems, this is exactly why I created The Agentic Development Blueprint. It pairs naturally with the newsletter issue if you want both the strategic model and the practical build path.
If your team wants help applying these patterns to real delivery workflows, infrastructure automation, or internal platform tooling, my consulting services are built for that kind of work.
This was the overview. The newsletter issue has the step-by-step implementation → Subscribe
Top comments (0)