Skills, Agents, and Slash Commands: Three Levels of Delegation

The main session burns three times more tokens. Takes twice as long. Loses visibility into what the sub-agent did. You delegated to abstract and gained opacity instead. That's the typical result of spawning an agent where a skill would have done the job.

Every serious harness exposes at least three ways to package reusable behavior. In Claude Code these are skills, agents, and slash commands. Each lives at a different level of delegation, pays a different cost, and fails in a different way. Confusing them is the first mistake when extending a harness.

The general rule: use the cheapest level that solves the problem. Agents are expensive in tokens, time, and isolation overhead. Skills cost nothing at invocation time. Slash commands are nearly invisible. Resist the instinct to spawn agents for everything.

The three levels

Slash command is the lightest: a text shortcut that expands into a prompt. Like an editor macro. Zero cost beyond what the prompt would already consume. Failure mode: a badly written prompt generates a bad response.

Skill sits in the middle: a named package with instructions, optional scripts, examples, and rules for when to apply. The model reads the description and decides when to invoke it. It doesn't create a sub-session, you stay in the same tick. Cost: whatever the skill adds to context. Failure mode: an ambiguous skill gets applied at the wrong moment.

Agent is the heaviest: spawns a new model session with its own system prompt, its own tools, and its own memory. Can run Haiku while the main session uses Sonnet. Runs in isolation and returns only a summary. Cost: full tokens for the sub-session plus setup overhead. Failure mode: the agent decides wrong and you don't see the tool call chain until the summary arrives.

When to use each level

Signal	Use	Why
"Whenever I type X, do Y"	Slash command	Pure shortcut, no logic
"When the problem fits this family, follow this procedure"	Skill	Recipe with contextual discrimination
"I want to spend tokens on this while I do something else"	Agent	Parallelism
"This task needs tools the current session doesn't have"	Agent	Tool surface isolation
"I want a different model for this sub-task"	Agent	Per-task model selection
"This sub-task can fail without contaminating the context"	Agent	Sandboxing

The last column reveals the real purpose of agents: isolation. If you don't need isolation, different tools, a different model, or a sandbox, you probably don't need an agent.

Slash command in practice

A slash command lives in a skill file with minimal frontmatter:

---
description: Rebuild + deploy the blog after a content change
---

Run in order:
1. Render markdown to HTML+CSS in the output directory
2. Sync output to the static server via rsync
3. Report the total number of pages rendered

The operator types /rebuild-blog. The harness expands the text above, sends it to the model, the model executes. No new agent, no isolation. The main session retains full awareness of what happened.

Slash commands serve repetitive rituals where you always run the same sequence. When the ritual diverges based on context, you've moved into skill territory.

Skill in practice

A skill is a recipe with discrimination. It has frontmatter declaring its domain, and the body describes when to apply it and how to proceed. The key difference from a slash command: a skill is invoked by the model when it detects the context, not by the operator typing a command. The operator doesn't need to remember to call it. The model reads the description of all available skills at session start and decides when one applies.

A well-designed skill has three parts: trigger (when to apply), anti-trigger (when not to apply), and procedure (numbered steps). A skill without an anti-trigger gets misapplied.

---
description: Code reviewer -- analyzes diff and reports technical problems
---

Use when:
- Operator requests review of a commit, PR, branch, or diff

Do not use when:
- Operator wants refactoring (use refactor instead)
- Question is about style/lint (delegate to appropriate tool)

Procedure:
1. Identify the target diff
2. Read the full diff
3. For each modified hunk, look for: type invariant violations,
   try/catch in projects that ban it, missing error handling in critical paths
4. Report in format: file:line -- description in 1-2 sentences
5. If nothing found: return "LGTM" with no additional text

Agent in practice

An agent is a complete sub-session. It's created via a dispatch tool inside the main session. The harness instantiates a new model with its own system prompt and tools, runs it to completion, and returns only the final text to the caller. The main session receives only that final text, not the internal tool call chain. That's intentional: you delegated the work, received the result, context didn't balloon.

Cases where an agent is the right choice:

1. Different model: main session on Sonnet, but you want exploratory search across 60 files. Spawn an agent with Haiku, 10x cheaper, sufficient for Read and grep.

2. Different tools: main session has Write enabled. You want an auditor that only reads. Spawn an agent with Read and Grep only, no accidental write possible.

3. Parallelism: three independent hypotheses to investigate. Spawn three agents in parallel, each with its own sub-prompt. Receive three summaries when all finish.

4. Disposable context: analysis that will consume 50k tokens reading logs. Spawn an agent, when it finishes the 50k disappears, leaving only a 500-token summary.

Anti-pattern: spawning an agent when a skill would do

The standard confusion: main session sends an agent to do X. Agent runs. Agent returns a summary. Operator needs the detail the agent saw but didn't surface. Main session doesn't have it. The detail is gone.

Diagnosis: the task didn't need isolation. It was work the main session should have done itself, guided by a skill. You paid the agent cost and still lost information.

The inverse rule: only spawn an agent when you can articulate which of the four reasons justifies it. Different model? Different tools? Parallelism? Disposable context? If none of those apply, use a skill.

Related anti-pattern: agent with a vague prompt like "investigate the bug and fix it." Agent investigates, writes its own interpretation of the bug, concludes it fixed things. Main session receives "fixed." Nobody saw the actual diagnosis. When the bug resurfaces in production a week later, you discover the fix didn't fix anything.

The correction: agents investigate or agents fix, never both at once. Dispatch the investigator, receive the diagnosis, you decide whether the proposed fix is correct, then apply it.

Composing the three levels

A real-world scenario showing all three working together:

The operator types /triage 4421 (slash command). The harness expands this into a bug triage prompt for issue 4421. The model identifies that the triage skill applies to this context. The skill instructs: read the report, identify hypotheses, spawn a read-only investigator agent with the most likely hypothesis. The model executes the skill, spawns an agent with Haiku and tools restricted to Read. The agent investigates and returns "Confirmed: recipient's domain has been on SES blacklist since the 18th." The main session receives the diagnosis and presents it to the operator.

Slash command was a text shortcut. Skill did contextual discrimination and procedure. Agent did isolated, cheap investigation. Each level did what it does best.