Rules, Commands, Skills, Hooks, and Agents Explained

Rules, Commands, Skills, Hooks, and Agents Explained

Rules constrain recurring decisions. Commands package an explicit invocation. Skills provide reusable knowledge or a workflow. Hooks react automatically to lifecycle events. Agents own delegated work inside a separate role or context.

Those definitions are a useful mental model, not an industry standard. Claude Code, Codex, Antigravity, Cursor, and community agent harnesses use overlapping words with different discovery, precedence, and enforcement behavior. Always verify the current documentation for the tool that will execute the configuration.

One job for each mechanism

The smallest fitting mechanism is usually the easiest to review. A naming convention does not need an agent. A deployment procedure does not belong in an always-loaded root file. A security boundary that must always block an action should not rely only on persuasive prose.

Rules keep recurring decisions consistent

A rule says how work should be done when a condition applies. It may define test expectations, naming, architecture, data handling, or a prohibited action.

In Claude Code, persistent project guidance can live in CLAUDE.md, while .claude/rules/ can hold more focused material and support path matching. Anthropic's extension comparison says root context loads every session, path-scoped rules can load for matching files, and skills load on demand.

Codex uses a different hierarchy. OpenAI's AGENTS.md guide describes repository instructions collected from the project root toward the current working directory. More local files refine the context for that subtree.

A rule should name its scope and evidence. “Use the repository's migration command and run the schema checks” is actionable. “Be careful with the database” is not.

Rules are guidance unless the harness gives them an enforcement mechanism. If a forbidden file must never be written, permissions or a blocking hook provide a stronger boundary than a sentence asking the model not to write it.

Commands create a deliberate entry point

A command is a named action the user invokes to begin a familiar workflow. In older Claude Code configurations, these were often called custom slash commands. Anthropic now presents custom commands as part of its skills model while continuing to support .claude/commands for compatibility in the current product.

Commands are useful for frequent starts: review this change, prepare a release plan, investigate a failing test, or summarize the active branch. They reduce retyping and make the expected input visible.

A command should remain explicit about what it will do. If /release can publish, the invocation needs a clear approval boundary. If it only prepares artifacts and checks readiness, its name and output should make that limit obvious.

Do not use a command merely to hide a long prompt. Give it inputs, outputs, prerequisites, stop conditions, and a versioned owner.

Skills hold reusable capability

A skill combines reusable instructions with optional references, examples, and scripts. It may teach a domain concept, define a review procedure, or perform a repeatable task.

Anthropic's skills documentation uses SKILL.md as the required entry file and allows supporting material in the same directory. OpenAI's Codex skills guide follows the same entry-file convention and progressive-disclosure idea. The exact scopes and selection behavior differ.

The distinction from a rule is loading and purpose. A rule describes a recurring constraint that should be available for matching work. A skill is a capability used when a task needs it.

The distinction from a command is also imperfect. A skill may be invoked by name like a command, or the model may select it from its description. The useful question is not which label sounds right. It is whether the capability should be automatic, explicitly invoked, or selected when relevant.

Scripts inside a skill make it executable software. Review their dependencies, filesystem access, network calls, credential use, and output before distribution.

Hooks respond to events

A hook runs when a supported lifecycle event occurs. A pre-tool hook may validate or block an action. A post-tool hook may inspect the result. A session-start hook may load state. A stop hook may run checks or record a summary.

Anthropic's hooks guide currently supports command, prompt, HTTP, and agent-based hooks. The documentation says agent hooks are experimental and recommends command hooks for production workflows. It also notes that a post-tool hook cannot undo an action that already happened.

Hooks are appropriate when timing matters and behavior must happen consistently. Formatting a changed file, rejecting a dangerous command, or recording a test result can fit an event.

They are not a substitute for judgment. A hook that tries to decide whether a feature is good, whether a legal statement is correct, or whether a release should happen may encode a false sense of certainty.

Hooks also add operational risk. They can run code automatically, consume time, expose environment data, or flood the agent context with output. Review the event, matcher, command, timeout, exit behavior, and failure mode.

Agents own delegated work

An agent is a worker with its own instructions and, depending on the harness, its own context, model, tools, permissions, skills, memory, and workspace.

Anthropic's subagent documentation exposes fields for tools, disallowed tools, model, permission mode, maximum turns, skills, hooks, memory, background work, and worktree isolation. A subagent returns a summary to the main conversation rather than carrying every intermediate detail into the main context.

That makes agents useful for bounded research, review, implementation, or verification. A security reviewer can inspect a patch without becoming the same worker that authored it. A documentation task can read many files and return a concise result.

Delegation does not remove accountability. The parent or human integrator still needs to define the outcome, limit authority, resolve conflicting results, and verify the combined change.

An agent should not be created merely because a task has several steps. Use a skill in the current context when the work benefits from shared state. Use a separate agent when isolation, specialization, parallelism, or a clean context materially improves the result.

sequenceDiagram
    participant U as User
    participant M as Main agent
    participant S as Skill
    participant A as Review agent
    participant H as Hook
    U->>M: Invoke feature workflow
    M->>S: Load implementation procedure
    S-->>M: Steps and acceptance criteria
    M->>M: Apply scoped rules and edit
    H-->>M: Run matching validation
    M->>A: Delegate independent review
    A-->>M: Findings and evidence
    M-->>U: Change, checks, and unresolved risks

How the parts compose

Consider a request to add a billing endpoint.

The root repository instruction establishes the architecture, approved package manager, required tests, and authorization boundary. A scoped rule applies data-access conventions to the billing directory. The user invokes a feature command or names the task. A skill supplies the repository's endpoint workflow and relevant API references.

The main agent implements the change. A post-edit hook runs formatting or static analysis. A specialized agent reviews authorization and data exposure in a separate context. The main agent then combines the implementation and review evidence for the user.

Each component has one reason to exist. The rule does not contain the entire endpoint tutorial. The skill does not claim permanent authority. The hook does not approve the business release. The review agent does not merge its own findings without integration.

Where ECC fits

The community project now called ECC provides examples of all these surfaces, plus installers, MCP configurations, memory, and orchestration. In episode 111A, Dalton used the earlier Everything Claude Code repository as a pattern source and adapted portions to another environment.

ECC is useful because its breadth makes the architecture visible. That breadth also means its configuration cannot be treated as inert Markdown. The pinned 2.0.0 checkout reviewed for this page includes executable hooks and scripts, optional connections, install behavior, and cross-harness adapters.

Read the [[ECC Review - What to Borrow and What to Review First|versioned ECC review]] before adopting it. The repository is not official Claude Code guidance, and a passing validator is not a security certification.

A decision test

Ask whether the behavior should be available every time matching work occurs. If yes, use a compact rule or repository instruction.

Ask whether a person should deliberately start the behavior by name. If yes, expose a command or explicitly invocable skill.

Ask whether the model needs reusable knowledge or a procedure only for certain tasks. If yes, use a skill.

Ask whether something must happen automatically at a specific event. If yes, use a hook, then review the code and failure behavior.

Ask whether the work needs a separate context, specialist role, permission set, or workspace. If yes, use an agent.

When two mechanisms could work, choose the one with less authority and less automatic execution. Add complexity only when the simpler surface fails a real need.

The underlying design rule

Agent configuration improves when knowledge, invocation, automation, and delegation stop being mixed together.

Rules govern recurring decisions. Commands make intent explicit. Skills package reusable capability. Hooks enforce or observe events. Agents isolate responsibility. Clear boundaries make the system easier to understand, test, and change.

Continue to [[How to Structure Repository Instructions for Coding Agents]] for the larger information architecture. If concurrent workers are the problem, read [[How to Run Multiple Coding Agents Without Collisions]].

Verification and disclosure

This explainer was checked on July 27, 2026 against current Anthropic Claude Code documentation, current OpenAI Codex documentation, ECC 2.0.0 at commit 6a9f075, and the E111A transcript.

Names, loading rules, precedence, permissions, hook events, and isolation features vary by harness and can change. AI assisted with research organization and drafting; evidence boundaries and final editorial decisions remain Dalton Anderson's.