# Rules, Skills, Commands, and Custom Agents: Knowing What to Use When

> A clear map of the four context management techniques available in modern AI coding tools, what each one is for, who triggers it, and how to combine them without creating a mess.

- **Source:** https://ainativesoftware.engineering/roadmap/day-4/rules-skills-commands-and-custom-agents-knowing-what-to-use-when
- **Site:** AI-Native Software Engineering — https://ainativesoftware.engineering/book

- **Day:** 4 · position 5 of 8
- **Reading time:** 6 minutes
- **Day overview:** [Day 4](https://ainativesoftware.engineering/roadmap/day-4.md)

A clear map of the four context management techniques available in modern AI coding tools, what each one is for, who triggers it, and how to combine them without creating a mess.

## Theory

Once you've used AI coding tools for a while, you end up with a growing folder of Markdown files. Rules files, skill files, prompt files, agent files. The labels shift depending on the tool (Cursor calls things rules, VS Code calls the same concept instructions, Claude Code uses CLAUDE.md), but the underlying ideas are consistent. The confusion isn't about the tools: it's about the mental model. Understanding the four layers clearly makes everything else fall into place.

### The one question that sorts it all out

Before deciding which layer to use, ask: **who triggers this?**

- The tool loads it automatically on every interaction → **Rule / Instruction**
- You explicitly invoke it → **Command / Prompt file**
- The agent decides it's relevant and pulls it in → **Skill**
- You need a completely different persona with different tool access → **Custom Agent**

| Layer | Who triggers it | Context cost | Best for |
|---|---|---|---|
| **Rules / Instructions** | Tool, always | Always loaded | Repo-wide non-negotiables |
| **Commands / Prompt files** | You, explicitly | Loaded when invoked | Reusable prompt templates |
| **Skills** | Agent, on demand | Loaded when relevant | Task-specific playbooks |
| **Custom Agents** | You, by switching | Full context swap | Isolated specialist workflows |

### Rules and Custom Instructions: the always-on layer

Rules (`.cursor/rules/`, `.github/copilot-instructions.md`, `CLAUDE.md`) are loaded into every single conversation. They set the ground rules the agent always follows without being asked. Keep them short and focused on things that should **never be ignored**: naming conventions, libraries to use or avoid, how tests must be structured, security constraints.

The critical rule for rules: **if you wouldn't want it applied when you're not thinking about it, it doesn't belong here.** "Never commit `.env` files" is a rule. "When writing a migration, follow these 8 steps" is not: that's a skill.

A practical anti-pattern: stuffing step-by-step workflows or long reference material into rules. This bloats the always-on context, dilutes the agent's attention, and slows every single interaction, even the ones that have nothing to do with those workflows.

### Skills: the on-demand expertise layer

A skill is a Markdown file that describes how to perform a specific type of task, following your team's conventions. The key difference from rules: the agent loads a skill only when the task is relevant, based on the skill's description metadata. Everything else stays out of context.

Think of it as progressive disclosure: the agent scans skill descriptions at the start of a session and pulls in the full content only when a task matches. This means two things about how you write skills:

1. **The description is for routing, not reading.** It must be specific and packed with the exact keywords you use when you describe these tasks. A vague description means the skill never gets loaded.
2. **The body is a procedure, not a wiki.** Checklists and success criteria, not long explanations. If you need reference docs, link to them from the skill rather than embedding them.

Skills work best for things you've done at least three times with the same steps: adding an endpoint, writing a migration, creating a component, reviewing a PR for security issues. Once you've done it twice manually, write the skill.

### Commands and Prompt files: the explicit invocation layer

A command is a saved prompt template you invoke by name. You type `/pr-review` or `/commit-message`, the tool injects the full prompt (with any variables filled in), and the agent executes it. Commands support parameters, so the template stays reusable across different inputs.

Commands are deterministic: you call them, the prompt runs. They are not loaded automatically and they don't require the agent to decide anything. This makes them ideal for workflows where you always want the same prompt structure, and where you know exactly when to use them.

The strongest pattern is to combine skills and commands: keep the complex, evolving logic in skills, and use commands as short ergonomic shortcuts that trigger those skills. When you update the skill, the behavior changes automatically. When you update the command, you're changing the invocation itself.

```markdown
---
name: pr-review
description: Review the current PR diff for bugs, missing tests, and security issues
---

Load the `pr-review` skill and review the following diff:

${selection}
```

### Custom Agents: the full persona swap

A custom agent is not just a different set of instructions: it's a different worker profile. It has its own system prompt, its own set of tools (often restricted to exactly what the task needs), and sometimes a different model. When you switch to a custom agent, the whole context changes.

Use custom agents when the task genuinely requires isolation or specialization that a skill can't provide. A planning agent that has no write access can't accidentally break things. A review agent running a slower, more capable model gives higher-quality feedback without costing that model on every autocomplete request. The handoff pattern (Plan → Implement → Review, with each phase running a different agent) is a clean way to structure complex multi-phase work.

**The practical rule:** reach for a skill first. Only upgrade to a custom agent if you hit a permissions scoping issue, need a fundamentally different model configuration, or find that the main agent's context is getting polluted by the specialization you're adding.

### How the four layers work together

A well-structured setup uses all four layers without overlap:

- **Rules** hold the project's non-negotiables (coding standards, banned patterns, security constraints)
- **Skills** hold the step-by-step playbooks for recurring task types (adding an endpoint, writing a migration)
- **Commands** hold the prompt templates you reach for explicitly (commit message, PR description, security review)
- **Custom Agents** handle isolated specialist workflows that need different tools or a different model

When you feel tempted to add something to your rules file, run this test first: does this need to apply even when the task has nothing to do with it? If no, it probably belongs in a skill or command instead.

**Theory resources**

- [Agent Skills vs. Rules vs. Commands – Builder.io](https://www.builder.io/blog/agent-skills-rules-commands)
- [Custom Agents, Agent Skills and Custom Instructions in Copilot – GitHub Community](https://github.com/orgs/community/discussions/183962)

## Practice

Run this in a repository you already know, not a toy project.

Audit the context setup for a real project you work in. The goal is to map what you have (or don't have) to the right layer, and fix at least one misplacement.

1. **List everything you currently use to give the agent context.** This includes rules files, instruction files, any prompts you retype often, and any agent configurations. If you have nothing, that's useful information too.

2. **Run each item through the routing test:**
   - Should this apply to every single task in the repo, even unrelated ones? → Rule
   - Do I invoke this explicitly when I want it? → Command
   - Should the agent load this only when the task is relevant? → Skill
   - Does this need a completely different tool set or model? → Custom Agent

3. **Find at least one misplacement.** The most common one: a step-by-step workflow buried in a rules file. Move it to a skill. Write a short description that accurately describes when it should load.

4. **Write one thing that's missing.** Pick the task type you do most often that you have no reusable context for. Write either a skill or a command for it (whichever fits the routing test better).

5. **Reflect:** After reorganizing, run a task that uses the new skill or command. Did the agent load the right context? Did anything still end up in the wrong place?

- **Previous topic:** [Custom Agents and Personas](https://ainativesoftware.engineering/roadmap/day-4/custom-agents-and-personas.md)
- **Next topic:** [Model Context Protocol (MCP): What It Is and Why It Matters](https://ainativesoftware.engineering/roadmap/day-4/model-context-protocol-mcp-what-it-is-and-why-it-matters.md)

---

_AI-Native Software Engineering by Alfonso Graziano (O'Reilly Media, Early Release; print edition February 2027). Every page of ainativesoftware.engineering is also served as Markdown: append `.md` to any URL. Index: https://ainativesoftware.engineering/llms.txt — whole site in one file: https://ainativesoftware.engineering/llms-full.txt._