Hello Curious Coders,

You’ve been working with Claude for a while now. You ask it to do things. It helps you. Life is good.

But then you notice something: you’re typing the same instructions over and over. “Run all the tests.” “Review my code for Elixir violations.” “Create a new OTP project with observability.” You find yourself copying and pasting prompts between sessions, tweaking them slightly each time.

And if you’re building complex projects, you probably need different expertise for different tasks. A frontend developer thinks differently than an API architect. An Elixir specialist has different judgment than a CSS expert. But your Claude session is just one Claude, one set of instructions, one way of thinking.

This is where sub-agents and slash commands come in. Together, they’re how you build a real AI toolchain that scales with your project without drowning your context window in repetition.

Prompts are code. You can think of them as fancy macros or code that writes code. You need to layer your prompts the same way you layer your Elixir code.

Today, we’re looking at four tools for doing that: rules, skills, sub-agents, and slash commands. They sound similar. They’re not interchangeable.

The “Who”: Sub-Agents and Specialized Delegation

A sub-agent in Claude Code is a named, configured AI persona with its own instructions, tool access, and model selection. When you activate one, you get a collaborator scoped to a specific domain, not the general-purpose assistant.

Bruce frames the decision clearly:

“We don’t have to clutter context with a task that’s important to get right but isn’t going to be done very often.”

– Bruce Tate

Three questions, basically. Is this important to get right? Does it come up infrequently? Would the details clutter your main conversation? If all three are yes, create a sub-agent.

On our course, Bruce creates a MixNewOTP agent to generate OTP apps with the right observability defaults. This is a perfect case: project setup errors cascade downstream, you don’t create new OTP projects all day, and the details (Elixir version checks, runtime tools, observer/wx setup) are useful but noisy in normal coding flow.

The important move happens before creating the agent: he primes context first. He asks for current version and dependency details, then uses that refreshed knowledge when generating the agent definition. That avoids freezing stale assumptions into automation. If you create an agent with outdated assumptions, you only automate mistakes faster. It is the same principle as gathering requirements before writing production code.

The deeper reason to reach for a sub-agent is control over runtime characteristics. You are choosing where and how something executes: a clean conversation with no accumulated context, a lighter model (Haiku instead of Sonnet) to save tokens on a well-scoped task, or isolation from the main thread so complex setup doesn’t pollute what comes next. That is what makes sub-agents distinct: not just that they’re specialized, but that you get to decide the execution environment deliberately.

Think about sub-agents as your project team: the main assistant is the generalist lead, and the sub-agent is the specialist you call when precision matters. You are not adding complexity. You are moving complexity to where it belongs.

The “What”: Slash Commands and Repeatable Workflows

If sub-agents are people, slash commands are procedures.

A slash command is a markdown template that captures instructions for a task you repeat. Instead of retyping the same prompt, you run a command.

There are built-ins and custom commands. Built-ins include /clear to reset context, and /compact to summarize and compress it, keeping momentum without carrying all the accumulated detail.

Custom commands live in .claude/commands/ as simple markdown files. Here is what a focused test command looks like:

# /test [path]

Run mix tests for the specified path or the whole project.

Instruction: Execute `mix test $1`.

- If the tests pass, say "All tests passed."
- If they fail, analyze the error and suggest a fix.

Now /test lib/myapp/user_test.exs runs that specific file. The $1 placeholder works like a function argument: same workflow, different inputs. Bruce demonstrates three patterns in class: a no-argument command like run-tests that always runs mix test; a single-argument version that targets one file; and a multi-argument form for parameterized workflows like assigning a pull request.

Custom commands can be project-scoped (live in the repo, travel with the codebase) or system-scoped (live in your personal environment, follow you across projects).

This is where automation starts to compound. You stop rewriting instructions and start invoking named behavior.

Decision Framework: Rule, Skill, Sub-Agent, or Slash Command?

When should you use each layer?

Rules apply always, automatically, across every conversation. Coding conventions, formatting defaults, architectural constraints. They require no invocation. They’re just present.

Skills are your default reach — Bruce puts it at about 70% of situations. A skill is a portable, reusable package of logic: a markdown file that Claude discovers and applies automatically. It doesn’t execute as a separate process — it shapes how the AI approaches a class of problem. Preferring pipes over with when building functional cores. Always checking for missing test coverage before suggesting a fix. That’s judgment encoded as a reusable pattern. Skills are for the how, not the what.

Sub-agents are for complex tasks that would otherwise bloat your main conversation. Running a 50-file test suite. Parsing verbose logs. Heavy, isolated setup work. Not just “I need expertise,” but: should this run in a clean conversation with no accumulated context? Should this use a lighter model to save tokens? Should this be isolated from the current thread? A Phoenix accessibility auditor, an OTP release setup expert, a performance profiler. These are all cases where you’re deliberately picking the execution environment, not just delegating to a specialist.

Slash commands are for precision: specific, manual shortcuts (/name) to invoke a particular skill or instruction immediately. Repeated tasks that don’t require a runtime decision — run tests, generate changelog, prep pull request. If you find yourself retyping the same instructions, a slash command removes that friction without the overhead of a full agent.

MCP servers are the bridge to external systems. Connecting Claude to your SQL database, integrating it with a third-party API, giving it access to tools that live outside the conversation. This is infrastructure, not automation.

When you’re unsure, these concrete cases cut through the ambiguity:

• “I need to refactor a file according to specific style rules” → Skill.
• “I need to run a 50-file test suite and fix errors” → Sub-agent.
• “I want to quickly invoke a prompt I wrote for pull request review” → Slash command.
• “I want to integrate my SQL database into my workflow” → MCP server.

The shortcut: if you’re encoding judgment about how to approach a problem, reach for a skill. If you’re isolating heavy or complex execution, use a sub-agent. If you’re just removing repetition from precise tasks, use a slash command.

Why This Stack Works

These four tools are complementary, not competing. Rules reduce cognitive load by making conventions automatic. Skills reduce it by encoding judgment so you don’t re-derive it every session. Sub-agents reduce it by isolating execution: clean context, right model, right scope. Slash commands reduce operational friction by turning repetition into invocation. They solve different problems and work better as a stack than any one does alone.

Together, they turn ad hoc prompting into a maintainable system. Once encoded, these artifacts can be shared, versioned, and improved over time. The knowledge stops living in your head and starts living in the repo.

One thing worth doing periodically: review your tool folders and prune what you no longer use. A slash command that was essential during prototyping might be dead weight once the project matures. Delete commands you haven’t used in a month. Update sub-agents when your stack changes. A cluttered toolchain adds cognitive load just like cluttered code does.

Build Your First Toolchain This Week

Start small:

1. Pick one task you keep retyping and make it a slash command.
2. Pick one recurring judgment call, a pattern you keep re-explaining, and encode it as a skill.
3. Pick one high-risk, low-frequency task and make it a sub-agent. Think about the model and context scope deliberately.
4. Run all three for a few days and refine.

You do not need a perfect framework on day one. You need one useful automation that survives real work. The key is to separate what always applies (rules), how to think about a problem (skills), how execution should run (sub-agents), and what to do repeatedly (slash commands).

That is the core move in building an AI toolchain that actually holds up over time.

– Paulo & Bruce