🦄 Skills don’t magically make your agent smarter. They change when context is loaded.
I intended to add Copilot skills to the list of topics I’ve written about, but it quickly turned into a behavior discussion instead of a how-to. Honestly, the same patterns behind custom agents, reusable prompts, and repo instructions all apply here. If you really want to understand a skill, then the mechanism matters more than writing the file.
Most frustration I see comes from expecting improved agent intelligence instead of selectivity. The truly interesting part is knowing when they help… and when they quietly make things worse. 🚦💎
What Skills Actually Change 💳
I’ve been rotating between Claude, GPT-5.2, and Gemini long enough to notice a pattern: most friction isn’t about model capability. It’s about context.
Once you regularly switch agents, you start seeing how much behavior differences come down to what each system loads, when it loads it, and how aggressively it summarizes what you gave it.
That’s where skills start to matter.
Skills reduce context overload by deferring detailed instructions until the moment they’re relevant. When written well, they feel like relief. When written poorly, they introduce overhead: lookup cost, planning cost, and extra reasoning steps before execution begins.
That overhead accumulates. Which is why I’m more interested in when skills should not exist than in how many you can create with the free space.
🦄 Across tools, the bigger difference isn’t “which model is smarter.” It’s how each agentic system decides what context deserves attention.
Instructions vs Skills 🧷
Metaphors always land faster than jargon for me. So here’s the one that stuck for me: "Bob the Builder".
- The agent is the builder.
- Instructions are the blueprints.
- Skills are the tools.
Blueprints describe what is always true. If you’re building a house, the structural plan does not change because you switched from wiring to drywall. In a repository, that’s what belongs in .github/copilot-instructions.md: guidance that is universally applicable and always loaded for every task.
Skills are conditional. You wouldn’t scatter every possible tool across the floor before starting a task. You grab what’s needed when you need it. Loading everything up front slows you down—and missing the one tool that actually matters often changes the outcome entirely.
That distinction is even more important now that context bloat is a real constraint. Long instruction files get summarized and those summaries will drift from the original intent. The most important line you were relying on for tone or guardrails is often the first casualty.
A skill avoids that by staying out of baseline context from the start.
At runtime, only the skill’s name and description are visible to the agent. It evaluates whether the current task matches that description. If the skill is relevant, then—and only then—it loads the full SKILL.md.
When a skill isn't activated, the agent didn’t “forget”—it never saw those details in the first place.
💡 ProTip: GitHub’s docs on agent skills and Claude Code’s skills docs are worth reviewing if you want the official mechanics behind activation.
Skill Structure and Activation 🪛
A Copilot skill is defined by a SKILL.md file. For repo-level skills, the structure looks like this:
.github/
|-- skills/
| `-- your-skill-name/
| `-- SKILL.md
The directory tree itself doesn't matter as much as when the agent activates it.
Only the skill’s metadata is evaluated initially. If the description matches the task, then the agent loads only the SKILL.md file and treats its contents as procedural guidance.
If you extend a skill with additional files, they are invisible unless explicitly referenced and deliberately loaded.
This separation is the entire value proposition of a skill:
| Before activation | After activation |
|---|---|
| Operates on inferred repository patterns | Executes defined procedural rules |
| Uses baseline instructions only | Uses baseline instructions + skill guidance |
| Optimizes for general applicability | Optimizes for task-specific behavior |
💡 ProTip: Copilot also checks
.agents/skillsand.claude/skills(globally and per repo). That makes cross-tool skill reuse feasible without duplicating logic unnecessarily.
Anatomy of SKILL.md 🧬
The SKILL.md file defines both activation metadata and execution guidance. The name and description are always visible to the agent. The rest of the file becomes active only after invocation.
Skills can mirror:
- a custom agent
- a reusable prompt
- a custom instruction
- or a hybrid of all three
Below is a simplified example designed to activate only when editing a CHANGELOG.md file:
---
name: changelog-writer
description: Rewrite changelog entries with cheeky, narrative flair following project conventions. Use this when asked to rewrite or update CHANGELOG.md entries.
---
## Execution Workflow
When invoked to rewrite a changelog entry:
1. **Read CHANGELOG.md** to extract tone and structure
2. **Identify release type and breaking changes**
3. **Select emoji(s)** appropriate to release theme
4. **Craft italicized opening quote**
5. **Write body content**
6. **Validate links, formatting, and breaking-change visibility**
The key observation here isn’t the workflow itself. It’s the activation boundary. Without activation, none of that logic exists in the agent’s working memory.
🦄 The full version lives in my awesome-github-copilot repo if you want to inspect it more closely.
One Sentence Version 🐎
If a behavior must apply consistently, it belongs in repository or global instructions.
If a behavior is conditional, procedural, or task-specific, it belongs in a skill.
A skill should feel like a tool you occasionally reach for—not a consistent rule the agent has to rediscover on its own every session. However, once instructions grow large enough, they stop acting like baseline context and start acting like noise. At that point trimming becomes more valuable than adding.
In case it helps, this is the prompt I use when reducing instruction bloat for newer LLMs:
Review #copilot-instructions.md and optimize for AI consumption. Remove information that can be inferred from repository structure or code usage. Eliminate duplication and anything that does not improve clarity or reduce ambiguity. Preserve personality and tone directives. The final file should prioritize agent understanding over human readability.
💡 ProTip: Back up the original first. Agents are confident editors and occasionally confident editors erase the one line that mattered most.
🛡️ Behind the Curtain
I wrote this post, and ChatGPT helped like a well-defined skill. I made the final calls—it activated when needed and stayed out of the way otherwise.
Top comments (2)
This is a great breakdown of how to handle context. As a CS student currently getting comfortable with Python and Git, the analogy of tools vs. blueprints really clicked for me. It’s a good reminder that even with AI, being organized and modular with instructions is just as important as writing clean code. Thanks for simplifying the magic behind it!
Ai is now future