After writing about terminology and context, I wanted to put down how this translates to my daily workflow.
Prompts
The prompt is the direct request for the task in front of me. What I have learned to be deliberate about is naming the context up front (the specific files, folders, or URLs) instead of hoping the agent finds it. Also be clear about scope or stop signals by giving it a instructions like “stop if the tests fail” or “stop before touching server code”. Without one the agent keeps going, and I end up reviewing a much bigger diff than I asked for.
Instructions
Instructions live in AGENTS.md, or .github/copilot-instructions.md for Copilot, and are read automatically on every request. That is the whole trade-off. They are reliable, but you pay for them every turn.
What works well here is examples, good and bad, because the agent replicates what it sees. Mine are mostly prohibitions I got tired of repeating, things like “never add yourself as co-author on commits” or “never edit files marked auto-generated”. The instructions should be short, checkable, and valid for all tasks I am working on. Anything that fails that test does not belong in the file.
Skills
I covered what a skill is in the terminology article, but what makes a good use case for it?
Global vs project skills
An agent loads only a skill’s metadata until it decides the skill applies, and reads the body after that. This also applies to global skills but that does not make global skills ‘free’. Every global skill puts its description in front of the model in projects even when it is irrelevant or half-matching the task (which might cause it to be pulled in). Project skills do not have that problem because they are meant for the specific project. My current rule is global only when I would want it in every repo, and project skills for everything else.
When to make a skill
Two clear signals to start thinking about a skill. The first is repetition. If I paste the same paragraph into a third prompt, it was reusable two prompts ago. The second is a recurring failure by the agent, which means there is a gap to close. This can be a knowledge gap, an execution gap, or a tool guidance gap. If a skill can help close that gap, use it :-).
| Gap category | Purpose | Examples |
|---|---|---|
| Knowledge gap | Add what the model does not know to steer the agent to the desired outcome and prevent guesswork. | Up-to-date knowledge, company-specific conventions, edge cases and pitfalls, patterns. |
| Execution gap | Describe the preferred way of working. | Order or phases, gates and stop conditions, preferences, output expectations, quality bar. |
| Tool guidance | Help the agent use the correct tool, which can also reduce token consumption. | When to use a CLI, script, API, or other tool, and how to use it. |
| Executables | Combine dynamic and deterministic behavior through enhanced scripts. | Give vague instructions that the model can interpret and translate as input for a script. |
Maintaining skills
The thing with skills to keep in mind is that they can be short lived. A model gets better and the workaround you wrote becomes noise, a tool changes its flags and the skill now teaches the wrong command, the project moves on and the skill becomes (partly) obsolete.
Sometimes deleting a skill, or part of it, is the best option. Evaluate from time to time by running the same task with and without it. When a skill fires and the result is worse than not having it, that is a clear sign to trim it down instead of expanding it.
Skills vs instructions
To recap, if it always applies, put it in the instructions file. If it is only relevant to a subset of tasks, make it a skill.