Introduction#
Rules, skills, and commands are how you encode intent directly into the tools so the agent starts each task already knowing your standards. When AI is the primary consumer, letting it draft these first usually produces clearer execution structure, while you keep policy and final approval.
The exact filenames and formats here belong to whatever tool you are using and will drift over time, so I am going to talk about the three by what they do rather than by where they live on disk. The functions are durable even when the syntax is not. Get the functions right and you can re-implement them in any agentic editor that comes along.
Encoding Intent into the Tools#
The first realization that changes everything is that durable instructions do not belong in every prompt. If I find myself typing the same guidance into a new chat for the third time, that guidance is not a prompt, it is a standard, and standards belong encoded in the tooling where the agent reads them automatically. Re-explaining your conventions every session is a tax you pay forever for work you could do once.
Encoding intent is the difference between a generic assistant and one that actually knows your project. Everything about the editor and the workspace is configuration. This is the part that carries your judgment forward, the naming patterns, the boundaries, the definition of done, and the handful of things the agent should never do. Once those live in the tooling, every task starts from your standards instead of from a blank slate, and the quality floor of the agent’s output rises across the board.
The leverage compounds because it is reusable. A standard you encode once applies to every future run, every teammate who shares the repository, and every model you rotate through. You are improving the baseline that all conversations start from, not just one of them, which is a far better place to spend your effort than perfecting individual prompts that vanish when the chat closes.
When AI Should Draft First#
Here is the principle that surprises people. Since the agent is the one reading and following these artifacts, the agent should write the first draft of them. Match the writer to the reader. The agent writes instructions in a shape that other agent runs parse cleanly, it draws sharper boundaries than I tend to, it remembers to include the edge cases and verification steps I would skip, and it stays consistent when the same artifact runs many times. It is simply better at writing for itself than I am.
That is not the same as handing over ownership, and the distinction is non-negotiable for me. I decide what problem I am solving, what is in scope and what is not, what good looks like, which risks are unacceptable, and whether the final version ships. The agent drafts, and I approve. The boundary is clean. AI owns the format and the structure, and I own the truth and the policy.
The reason this matters is that an agent always has an answer. If your intent is vague, it will not stop to ask, it will confidently continue with a guess, and a confident wrong guess is worse than no answer at all because it repeats faithfully every time the artifact runs. So the order of operations is fixed. Get the policy right first, in plain language, then let the agent handle the formatting second. Optimize truth before you optimize structure, never the reverse.
Rules, Skills, and Commands Compared#
The three artifacts solve three different problems, and knowing which bucket a need belongs in is half the work. A rule is passive and always on. It is the standing guardrail the agent carries into every task without being asked, the right home for the things it should never do and the conventions it should always follow. Rules are where restraint lives.
A skill is an active, multi-step runbook for a process you repeat that has a specific order of operations. It is what you reach for when a task has real structure, such as scaffolding a new data model along with its tests and documentation in one disciplined pass. A command is a trigger-based shortcut, a quick action you fire on demand for a repetitive task you want to invoke explicitly rather than have running in the background. Roughly, a rule is always there, a skill is a procedure you invoke for complex work, and a command is a fast button for a small repeated action.
Whichever you reach for, the upgrade that matters most is the same across all three, and it is scope boundaries. Almost every time an agent does something strange, the root cause is not the model, it is that nobody told it where the walls are, so it invented its own. Stating explicitly what is in scope and what is out of scope removes most reliability problems on its own. Right behind it is the definition of done, the one section most people skip and the one that most determines whether the agent knows when to stop. An artifact with clear intent, explicit scope, ordered steps, and real done criteria will outperform a vague one every single time.
Keeping Them Maintained#
Encoded intent rots. A rule that fit the project perfectly in the spring will start causing problems by the fall, because the project moved and the rule did not. This is not a failure of the approach, it is simply the cost of having standards in a living system, and the fix is to treat maintenance as part of the practice rather than a surprise.
The decay has recognizable symptoms. The agent starts apologizing and promising to follow a rule it just ignored. You find yourself manually overriding its output on the same task again and again. An artifact references files or folders that have since been renamed. Any of these is a signal that the encoded intent has drifted out of sync with reality, and the longer you leave it, the more it degrades every run that depends on it.
When you spot decay, do not silently patch it by hand. Feed the broken artifact back to the agent, explain why it is failing now, and have it produce an updated draft, the same draft-first loop that created it. I also keep a standing habit of asking the agent to update any relevant documentation at the end of a task, so the encoded intent stays current as a side effect of normal work. The opposite failure is just as real, though. Do not create artifacts for ceremony. Every rule you add is a rule you must maintain, so keep only the ones that earn their place by consistently improving real work.
Putting It Into Practice#
- When you type the same guidance a third time, stop and encode it as a rule, skill, or command instead.
- Let the agent write the first draft of any artifact it will be the one to read and follow.
- Keep ownership of the policy, the scope, the definition of good, and the decision to ship.
- Get the intent correct in plain language first, and let the agent handle formatting and structure second.
- Sort each need into the right bucket, namely an always-on rule, a multi-step skill, or an on-demand command.
- Make scope boundaries and done criteria explicit, because they prevent most strange agent behavior.
- Treat decay as routine maintenance, regenerate drifted artifacts with the agent, and refuse to keep any rule that exists only for ceremony.
