AI Coding Agents Explained: Rules, Commands, Skills, MCP, Hooks

If you are an engineer today, the challenge is no longer whether AI can help you write code. The challenge is the flood of tools and concepts.

Every few weeks, there is something new. Agents, rules, skills, sub-agents, MCP, hooks. Each introduces its own vocabulary, and most explanations jump straight into features without explaining why any of these concepts exist in the first place.

So you try them. Some things feel powerful. Some feel magical for a moment. Then the setup starts to feel fragile and hard to reason about.

The problem is not that these concepts are bad. The problem is that they are rarely taught as parts of a system.

I went through the same confusion. The goal of this post is to give you a mental model you can apply regardless of the tool, so you know when a concept matters and when it is just noise.

The core mental model

An AI coding agent repeatedly does this:

1. Read persistent context
2. Interpret intent
3. Plan an approach
4. Generate or modify code
5. Optionally observe results
6. Iterate

Every concept exists to control one specific step in this loop.

• Rules provide constraints.
• Commands initiate execution.
• Skills guide methodology selection.
• Sub-agents limit responsibility.
• MCP enables external interaction.
• Hooks enforce guarantees.

If two concepts try to control the same step, confusion follows.

Rules

Rules exist to separate constraints from execution. Without this separation, engineers keep encoding constraints inside prompts, and the agent’s behavior becomes unstable as soon as tasks change.

They are consulted by the model whenever it approaches a task, regardless of what the task is.

What it is in practice

Rules are persistent constraints that apply across all agent interactions, usually written as Markdown text.

They describe what must always be true, regardless of the task being executed. Rules live outside individual requests and do not change from task to task.

In practice, rules define boundaries rather than actions.

What it is good for

Rules are good for enforcing invariants.

They protect things you do not want the agent to renegotiate every time:

• architectural boundaries
• dependency choices
• folder structure
• coding/testing conventions
• backward compatibility expectations

Once something is an invariant, it belongs in rules.

Example

To keep this grounded, we will use one example throughout.

You already have a Task API in production. Yesterday, you used an AI agent to add a new endpoint. Today, you want to add more features.

Two constraints matter:

• Existing behavior must not change.
• Tests must keep passing.

For the Task API, useful rules look like this:

• Validation logic must live in the domain layer
• No new dependencies may be introduced
• Existing test helpers must be reused
• Public API behavior must not change without explicit instruction

With these rules in place, prompts can stay short and focused on intent because constraints are no longer embedded inside them.

Common misunderstanding

The most common mistake is treating rules as behavioral coaching.

Rules like:

• Write clean code
• Think carefully before coding
• Refactor when appropriate

do not define constraints. They force interpretation.

If a rule requires judgment to apply, it does not belong in rules. It belongs in a skill or in human review.

Commands

Commands exist to express execution intent. Unlike skills, which define how a class of problems should be solved, commands describe what specific action the agent should perform right now. They answer the question: what should the agent do now?

They are invoked explicitly by you and tell the model what task to execute now.

What it is in practice

A command is a named or explicit instruction, typically stored as Markdown or plain text, sometimes with parameters.

Commands are scoped to a single action and executed in the current context.

What it is good for

Commands are good for:

• executing a specific change
• triggering a known workflow
• keeping interaction fast and direct

They work best when the intent is clear.

Example

Examples of commands are

• add input validation
• update tests
• create a new entity

Commands should not describe architecture, style, or process. That belongs elsewhere.

Common misunderstanding

Commands are often overloaded with policy.

Long commands that explain how to structure code, where logic lives, and what tradeoffs to consider are compensating for missing rules or skills.

When commands get longer over time, it is a signal that execution is no longer the only problem.

Skills

Skills exist to separate methodology from execution. They capture how you solve a recurring class of problems.

They are consulted when the model recognizes a task as belonging to a known category.

What it is in practice

A skill is a reusable instruction set that teaches the agent a specific way of working. It is a bundle of instructions plus optional tools, usually defined as Markdown plus scripts or tool bindings.

It is not a one-off request. It is a repeatable method.

What it is good for

Skills are good for:

• capturing repeatable engineering patterns
• reducing prompt repetition
• improving consistency across tasks
• encoding domain-specific practices once and reusing them everywhere
• executing tools or scripts as part of a known method

They remove methodology from commands and keep commands focused on intent.

Example

A validation skill might encode:

• how schemas are structured
• how errors are returned
• which edge cases must be tested

When adding validation, the model applies this skill during execution.

Common misunderstanding

Skills are often created too early.

If something does not repeat, it does not deserve a skill.

Sub-agents

Sub-agents limit who is allowed to act on a task by explicitly constraining scope, context, and responsibility.

They exist to prevent a single agent from making broad, cross-cutting changes when the task itself only requires a narrow, well-defined area of action.

They are invoked when work is delegated instead of executed directly.

What it is in practice

A sub-agent is a scoped agent with a specific responsibility and limited context, usually expressed as Markdown with structured metadata.

The main agent decides when to delegate and what authority the sub-agent has.

What it is good for

Sub-agents are good for:

• controlling blast radius
• separating concerns
• preventing unintended cross-changes

They reduce risk by narrowing responsibility.

Example

• Sub-agent A modifies validation logic only
• Sub-agent B updates tests only

Each sub-agent executes within its scope.

Common misunderstanding

Sub-agents are often framed as parallelism.

You rarely introduce sub-agents because you want things to run faster. You introduce them because a single agent handling too many responsibilities becomes unpredictable.

Their real value is containment: limiting what can change, where it can change, and why. Speed is a side effect at best, not the goal.

MCP

I have a separate, longer post about MCP. Please check it out.

Basically, it is invoked when the model needs real-world feedback instead of guessing. It also allows the agent to interact with systems.

What it is in practice

MCP connects the agent to tools, environments, or data sources.

The model calls MCP tools to observe outcomes it cannot infer from text alone.

What it is good for

MCP is useful for:

• validating assumptions
• running tests
• reading failure output
• querying external systems

Example

• running the external test suite after changes
• inspecting failing test output
• interact with the browser for testing
• query data from the database

Common misunderstanding

MCP is often treated as intelligence.

It does not improve reasoning. It improves feedback.

Hooks

Hooks exist to separate enforcement from reasoning. They run outside the LLM reasoning loop and are triggered regardless of what the model decides.

They guarantee that something always happens.

What it is in practice

A hook is a deterministic action triggered at a specific point in the workflow.

What it is good for

Hooks are good for:

• enforcing policies
• running tests
• formatting code
• blocking unsafe changes

Example

• run unit tests after file changes
• block edits to protected directories

Common misunderstanding

Hooks are sometimes used to encode decision logic.

If a hook needs reasoning, it belongs in a skill or sub-agent instead.

How this fits together

A stable setup looks like this:

• rules define constraints
• commands express intent
• skills capture repeated methodology
• sub-agents control scope
• MCP enables observation
• hooks enforce guarantees

You do not start with all of this.

Each layer exists because a specific problem appears.

A starter kit for working with AI Coding Agents

Once you understand the concepts above, a new problem usually appears.

You now know what rules, commands, skills, sub-agents, MCP, and hooks are for, but setting them up across different tools still takes time and cognitive energy. Each tool such as Cursor, Claude Code, Antigavity, Codex, OpenCode, etc has its own conventions, file locations, and wiring. The concepts are the same, but the setup friction is real.

This is the gap AI DevKit is designed to close.

AI DevKit is a starter kit for engineers who want to work with any AI coding agent in a structured way, without rebuilding the same scaffolding every time. It gives you a ready-to-run foundation so you can focus on building software, not on repeatedly re-learning how to wire agent workflows.

You still decide the rules. You still design the skills. You still own the system. AI DevKit simply removes the accidental complexity so you can start from a sane baseline instead of a blank slate.

AI DevKit is open source, and contributions are welcome from engineers who want to shape how practical AI agent workflows should look.

Closing

Coding AI agents are not assistants. They are execution systems with explicit control layers.

They do not decide what is important, what is safe, or what should change. They execute within the structure you give them, and they fail in predictable ways when that structure is missing.

Once you understand when each layer is consulted and what form it takes, new tools stop feeling overwhelming and start feeling composable. The agent ultimately reflects your system design decisions, not your intent, and responsibility for correctness, safety, and clarity still sits with you as the engineer.

If you want to read more about software engineering in the AI era, subscribe to my blog. I will keep sharing what I learn while building systems with AI in the loop.