# Rules, Commands, and Skills: The Three Layers of Agentic Coding > Most developers use AI coding assistants as fancy autocomplete. The ones getting 10x more out of them understand the difference between rules, commands, and skills — and use all three deliberately. - Published: 2026-03-14 - Tags: AI, dx, productivity, tutorial - URL: https://www.woza.ink/blog/rules-commands-skills-agentic-coding Most developers use AI coding assistants as fancy autocomplete. Ask a question, get an answer, copy-paste. Repeat. The developers getting an order of magnitude more out of them understand something different: an AI coding agent is a programmable collaborator. And like any collaborator, it works best when you give it **persistent context**, **repeatable workflows**, and **domain-specific expertise**. That's what rules, commands, and skills are. Three distinct layers. Three different jobs. Most people only use one of them. --- ## The mental model Think of it like onboarding a new engineer to your team. - **Rules** are the things you'd put in the team handbook. "We use tabs not spaces. PRs require tests. Never commit secrets." They don't need to be repeated every conversation — they're always on. - **Commands** are the SOPs (standard operating procedures). "To deploy, run these steps in this order." Repeatable, triggerable, procedural. - **Skills** are the deep domain knowledge you'd send someone to a course for. "Here's how to handle authentication in our system. Here's our architecture. Here's the full workflow for writing a feature end to end." Rules govern behavior. Commands automate tasks. Skills encode expertise. --- ## Rules — always-on constraints Rules are instructions the agent follows in every single session, without you having to ask. They live in a project-level config file (like `AGENTS.md` or `.cursorrules`) and get injected into context automatically. Good rules are: - **Unconditional.** They apply everywhere, always. "Use TypeScript strict mode." "Never use `any`." - **Short.** Rules aren't documentation — they're constraints. If it takes a paragraph to explain, it probably belongs in a skill instead. - **Behavioral.** They shape *how* the agent works, not *what* it knows. Tone, formatting preferences, safety guardrails, commit message style. ```markdown # AGENTS.md - Use pnpm, never npm or yarn - Prefer editing existing files over creating new ones - Never commit .env files - All components go in src/components/ ``` The failure mode with rules is over-stuffing them. Fifty rules is noise — the agent starts ignoring them the same way you'd ignore a style guide with 200 items. Keep it tight. Ruthlessly prune anything you could handle by convention instead. > Rules are your defaults. They shouldn't surprise you — they should just quietly enforce the things you'd correct anyway. --- ## Commands — repeatable, triggerable workflows Commands (sometimes called slash commands or custom commands) are procedures you trigger on demand. They're not always-on — you invoke them when you need them. The core use case: **anything you do more than twice** that involves more than one step. - `/review` — run a code review with a specific checklist - `/commit` — stage changes, write a commit message following your conventions, push - `/new-component` — scaffold a new component with the right folder structure, index file, and test file - `/sprint-status` — summarize what's done, what's blocked, what's at risk Commands are defined as markdown files with a prompt template. The agent reads the file, executes the steps in order, and returns the result. ```markdown # .claude/commands/new-component.md Create a new React component named $ARGUMENTS. Steps: 1. Create src/components/$ARGUMENTS/$ARGUMENTS.tsx 2. Create src/components/$ARGUMENTS/index.ts that re-exports the component 3. Add a basic test file at src/components/$ARGUMENTS/$ARGUMENTS.test.tsx 4. Follow existing component patterns in the codebase ``` The key distinction from rules: **commands are imperative, rules are declarative**. A rule says "always do X." A command says "when I say so, do these steps." Commands fail when they are too general. A `/help-me-code` command is useless. A `/scaffold-api-route` command that knows exactly which folder to use, which middleware to apply, and which test pattern to follow saves time. > Commands are the things you used to keep in a Notion doc that nobody ever read. Now they're executable. --- ## Skills — deep, loaded expertise Skills are the most powerful and least understood of the three. They're substantial context packages — detailed instructions, workflows, domain knowledge, and reference material — that get loaded into the agent's context when needed. Unlike rules (always on) and commands (triggered procedurally), skills are triggered by **task type recognition**. When you say "let's create a PRD" or "implement this story" or "run a code review," the agent loads the matching skill and suddenly has deep expertise on how to do that specific thing in your context. A skill might include: - A full workflow with stages and decision points - Templates and examples - Domain knowledge specific to your stack or process - Checkpoints and validation criteria - Edge cases and how to handle them The difference between a command and a skill is depth and intelligence. A command is a checklist. A skill is a methodology. ```markdown # skills/create-prd/SKILL.md You are acting as a product manager helping to create a PRD. ## Workflow 1. Start by asking 5 discovery questions about the feature 2. Draft the problem statement and success metrics 3. Break down into user stories with acceptance criteria 4. Identify technical constraints and open questions 5. Review with the user before finalizing ## Format Use this template: [template follows...] ## Quality bar A good PRD answers: who is this for, what problem does it solve, how do we know when it's done, what are we explicitly not building. ``` Skills are what take an AI assistant from "fast search engine" to "actual collaborator who knows what it's doing." > The rule of thumb: if you'd send a junior developer to a training course to learn it, encode it as a skill. If you'd put it in a team handbook, make it a rule. If you'd write it in a runbook, make it a command. --- ## How they work together The three layers compound. Rules set the baseline. Commands handle the repetitive. Skills handle the complex. A concrete example — writing a new feature: 1. **Rules** silently enforce that the agent uses your stack, your file structure, your commit format — without you saying anything. 2. You trigger a **command** like `/create-story` to scaffold the feature spec in the right format. 3. You invoke a **skill** like `dev-story` to actually implement it — the skill knows your architecture, your patterns, when to ask for clarification, and how to validate its own work. Without rules, every session starts from scratch. Without commands, you repeat yourself constantly. Without skills, complex tasks get shallow, inconsistent results. --- ## The practical takeaway Start with rules. They give you the biggest return for the least effort. Five good rules beat fifty mediocre ones. Then identify the two or three workflows you run most often and turn them into commands. The goal isn't to automate everything — it's to make the common things frictionless. Skills come last, and only where you need depth. They're expensive to write well and they need maintenance as your codebase evolves. A skill that encodes how you make architecture decisions, review code, or onboard a feature comes closest to cloning your own judgment. Most developers treat AI as a conversation partner. The ones shipping faster treat it as a programmable system. Rules, commands, and skills are how you build that system. --- --- *If you're using Claude Code specifically, the [BMAD method](https://github.com/bmadcode/BMAD-METHOD) is one of the most complete implementations of this pattern I've seen — worth digging into if you want to see all three layers working together in practice.* ## Notes 1. **quote** on "Think of it like onboarding a new engineer to your team": "'Agentic' because the new default is that you are not writing the code directly 99% of the time, you are orchestrating agents who do and acting as oversight. 'Engineering' to emphasize that there is an art & science and expertise to it." — Andrej Karpathy, February 2026 2. **context** on "They live in a project-level config file": The rules-file pattern has converged across tools under different names: Claude Code uses `CLAUDE.md` / `AGENTS.md`, Cursor uses `.cursorrules` (now migrating to `.cursor/rules/*.mdc`), and Windsurf uses `.windsurfrules`. The mechanism is identical: markdown injected into every AI request as persistent context. Windsurf caps rules at 6,000 characters per file and 12,000 total — a hard constraint that forces brevity. (https://docs.windsurf.com/windsurf/cascade/workflows) 3. **source** on "The failure mode with rules is over-stuffing them": The [awesome-cursorrules](https://github.com/PatrickJS/awesome-cursorrules) repository has over **36,900 GitHub stars** and 3,100+ forks — a community-curated collection of `.cursorrules` files organized by tech stack (Next.js + TypeScript, FastAPI, React Native, etc.). One community member published a collection of **879 `.mdc` rule files** for the newer Cursor format. The sheer volume suggests developers are treating rule authoring as a first-class engineering activity. (https://github.com/PatrickJS/awesome-cursorrules) 4. **source** on "Commands are defined as markdown files with a prompt template": Claude Code has unified commands and skills: files in `.claude/commands/` and `.claude/skills/` both create the same `/slash-command` interface. Skills can now spawn isolated subagents with their own context windows, restrict which tools the agent uses, override the model, and hook into lifecycle events. The old distinction between "command as checklist" and "skill as methodology" is now an implementation detail, not a structural one. (https://code.claude.com/docs/en/skills) 5. **note** on "detailed instructions, workflows, domain knowledge, and reference material": A SKILL.md file requires a YAML frontmatter header with `name` and `description`. But the real power is in the optional supporting files: templates for the agent to fill in, example outputs showing expected format, shell scripts the agent can execute to inject live data, and reference documentation. A well-built skill directory is essentially a self-contained expert system. (https://code.claude.com/docs/en/skills) 6. **quote** on "The three layers compound. Rules set the baseline. Commands handle the repetitive. Skills handle the complex": Simon Willison, speaking at the Pragmatic Engineering Summit in March 2026, described a pivotal moment: "the moment where the agent writes more code than you do." At that point, the developer's primary output shifts from code to context — the rules, commands, and skills that shape agent behavior become the actual product of your engineering work. 7. **counter** on "Start with rules. They give you the biggest return for the least effort": One caveat to the "start with rules" advice: Cursor users report that a well-crafted `.cursorrules` file can push AI suggestion acceptance rates **from 30% to 80%+**. But the flip side is real — over-stuffed rule files become noise. The 2026 Agentic Coding Trends Report from Anthropic emphasizes that vibe coding (typing prompts and hoping for the best) fails when code moves from prototype to production. The technique skips design, review, and testing. (https://resources.anthropic.com/hubfs/2026%20Agentic%20Coding%20Trends%20Report.pdf) 8. **context** on "Most developers treat AI as a conversation partner. The ones shipping faster treat it as a programmable system": According to Gartner's 2026 CIO Agenda, **64% of technology leaders** plan to deploy agentic AI within 24 months, and over 57% of organizations surveyed by LangChain already have agents running in production. The skills that matter are shifting toward architecture, system design, prompt engineering, and quality judgment — the exact skills encoded in rules/commands/skills files.