Part of the knowledge about a project is not a one-line constraint but a whole procedure: how to review an API, how to prepare release notes, how to build a migration plan. That is too long for an always-on rule and too specific to keep in your head and dictate anew each time. You need a place where the procedure lives in full but does not get in the way until it is needed. Between "always in the context" and "by hand from scratch every time" there must be a third option, and that third option is a skill.
There are two naive moves. The first is to write the procedure as one big always-on rule so it is "always at hand". The second is to paste it into the prompt again before every use. Both seem reliable: the first forgets nothing, the second keeps everything in view.
Both break on the same thing. A permanent procedure burns tokens on every turn, even when the task has nothing to do with it: ten steps of an API review are dead weight while you edit styles. A hand-pasted procedure is slightly different each time, drifts and accumulates copy-paste errors. The knowledge is there, but delivered in the most expensive and most fragile form. A skill removes both troubles at once: it is written once and in full, yet loaded only on demand.
Skills solve this as knowledge on demand. A project skill lives in .devin/skills/<name>/SKILL.md, a global one in ~/.config/devin/skills/ (on Windows, in %APPDATA%\devin\skills). The user invokes a skill as /name, and the model can pick it on its own if the model trigger is allowed. A skill enters the context only when relevant, rather than hanging around all the time. This is exactly the distinction for which Devin's documentation advises preferring skills to rules: an always-on rule pays with context all the time, while a skill pays only at the moment it is actually invoked.
The skill's construction explains why it is safer than a rule. It is a folder with a SKILL.md and, when needed, supporting files. A skill can restrict allowed-tools (read, edit, grep, glob, exec), add its own permissions with allow, deny and ask (they are additive to the session's base permissions, not a replacement), choose a different model and even run as a subagent with its own context window. The subagent and agent fields are marked experimental - pin a verified version if you rely on that behavior. A global skill is visible across all projects, a project skill only in its own and travels together with the repository, so the team gets it along with the code.
What makes a skill good: one skill, one finished result. Review an API, build a migration plan, prepare release notes - each has a clear input and a clear output. "All company standards" is a bad skill: it is too broad, goes stale fast and turns into a dump that cannot be verified. A narrow role is both precision and predictability.
The cost of breadth is not abstract. A bloated skill reproduces the same disease as a bloated rule, only loaded on demand: a lot of inapplicable text at the moment of invocation. Experimental fields may change between releases and quietly break a familiar launch. And a skill with wide permissions is a wider trust surface: the more it can do, the more you have to verify after it. So the breadth of a skill should be seen not as convenience but as debt: every extra tool and every extra permission you later pay for by verifying its result.
A skill is justified where there is a repeatable procedure with a clear result that you invoke deliberately. A narrow tool set and explicit permissions make the skill's intent verifiable: the frontmatter shows what it reads, what it changes and what it cannot do in principle. That is the practical value of a narrow role: not only a predictable result but also a known-in-advance boundary of what the skill is physically able to do to the project.
A skill must be verified as concretely as it was built. Invoke /name and confirm it loaded and stayed within its allowed-tools. Check that the result is exactly the single output the skill was created for, not something adjacent. If you rely on experimental subagent behavior, pin the version it works on and re-check after updates.
The typical failures repeat the mistakes of rules. A skill is turned into a knowledge dump - and both precision and verifiability are lost. Experimental fields are relied on without pinning a version - and the launch surprisingly changes after an update. A review skill is given write access "just in case" - and it stops being an independent look. The sign is the same: the skill does more than its name promises. Keep one result per skill, trim its tools, and trust on-demand loading to do its job.