Reusable Workflows: Slash Commands, Skills, and Iterative Refinement

The previous chapter was about standing instructions — the conventions that are always in scope. This one is about the workflows built on top of them: the multi-step tasks you run over and over, and the techniques for steering Claude toward exactly the output you want. Both are Domain 3. The first, slash commands and skills, is configuration I can confirm against the live tool. The second, iterative refinement, is a set of prompting patterns whose effectiveness is model-dependent, so those claims are model-dependent in magnitude. What’s not model-dependent, and heavily tested, is knowing which mechanism to reach for.

What these mechanisms are for

Two problems keep recurring once you use Claude Code seriously. The first: you have a task you do the same way every time — a release checklist, a code-review pass against your conventions, a specific refactor. Re-explaining it each session is wasted effort, and it drifts a little every time. The second: your first prompt rarely produces the final answer, and “try again, but better” is a poor way to close the gap.

This chapter’s mechanisms answer those two problems in turn. Slash commands and skills are the two ways to package a repeatable workflow so it exists as a named, reusable thing instead of a paragraph you retype. Iterative refinement is the set of techniques for steering an in-progress result toward what you actually meant. The first is about reuse; the second is about convergence.

The reason both matter is the same one behind the whole domain. Leaving a repeatable process implicit means doing it slightly differently every time. Hoping for a good result from a vague prompt means getting an inconsistent one. Naming a workflow makes it repeatable; steering with concreteness makes the result reliable. Neither is something to reach for on a one-off task, since a workflow you’ll run once doesn’t need packaging. But the moment something recurs, packaging it pays for itself.

Commands vs. skills: who decides when to run it

Both slash commands and skills are reusable, file-defined workflows, and the exam’s core question is the difference between them. It comes down to who decides when it runs.

A slash command is user-driven. You define it as a markdown file — .claude/commands/<name>.md (project-scoped, shared via version control) or ~/.claude/commands/<name>.md (user-scoped, personal) — and it runs only when you type /name. It’s an explicit invocation.

A skill is discovery-driven. It lives in .claude/skills/<name>/SKILL.md with YAML frontmatter, and Claude invokes it autonomously when it judges the task relevant, based on the skill’s description. You don’t have to remember to call it; Claude reaches for it when the moment fits.

That single axis — who pulls the trigger — is the whole distinction, and it decides which one fits. Commands for workflows you invoke on purpose, skills for capabilities Claude should apply on its own when relevant. A /deploy command you run deliberately is a command. A “review React components against our conventions” capability that should kick in whenever Claude touches a component is a skill. If you always know the exact moment you want it, make it a command. If you want it to fire without you having to remember, make it a skill.

Skill frontmatter, and the fork that matters most

A skill’s SKILL.md frontmatter configures how it runs, and three fields are exam-relevant:

context: fork: run the skill in an isolated sub-agent context, so its output doesn’t pollute the main conversation. This is the one to know cold. A skill that produces verbose output would flood the main session’s context if it ran inline — a full codebase analysis, an exploratory brainstorm. Forking it isolates that verbosity: the sub-agent does the noisy work and returns a summary, and the main conversation stays clean. It’s the context-isolation idea, applied to a skill.
allowed-tools: restrict which tools the skill may use during execution. A skill that only edits files can be limited to write operations, so it cannot run a destructive command even if something went sideways — the same structural-guardrail principle as a hook.
argument-hint — prompt the developer for required parameters when they invoke the skill without arguments, so a skill that needs an input asks for it instead of guessing.

Personal customization is a fourth thing to know: you can create a personal variant in ~/.claude/skills/ under a different name, so your version doesn’t override the team’s shared skill. (These are live Claude Code behaviors, confirmable directly.)

Skill or CLAUDE.md?

One more placement decision, adjacent to the CLAUDE.md hierarchy: when does a convention belong in a skill versus in CLAUDE.md? The line is always-loaded versus on-demand. CLAUDE.md holds universal standards that should shape every interaction — always in context. A skill holds a task-specific workflow invoked only when its task comes up. Putting a niche workflow in CLAUDE.md bloats every session’s context. Putting a universal standard in a skill means it only applies when Claude happens to invoke the skill. Universal and constant → CLAUDE.md; specific and occasional → skill.

Packaging handles reuse; the other half of the domain is convergence — getting Claude from a first attempt to the output you actually want. The techniques all rest on one insight: prose is interpreted inconsistently, and concreteness fixes it. A paragraph of description leaves room for the model to read it several defensible ways. A concrete example, a failing test, or a pointed question removes that room. The effectiveness of these techniques is a model-behavior claim: the closely related few-shot result in the precision chapter shows concreteness sharply improving output consistency. The patterns are the exam content.

There are four moves, and they work as a small toolkit rather than a list. Each fits a different kind of gap between what you got and what you meant:

Concrete input/output examples are the most effective way to communicate a transformation when a prose description keeps producing inconsistent results. Two or three examples of “this input → that output” pin down what words couldn’t.
Test-driven iteration — write the test suite first (expected behavior, edge cases, performance), then iterate by sharing the failures. The failing tests are precise, executable feedback, far better than “that’s not quite right.”
The interview pattern — have Claude ask questions before implementing, to surface considerations you hadn’t specified (cache-invalidation strategy, failure modes). Especially valuable in an unfamiliar domain, where you don’t yet know what you don’t know.
Batching vs. sequencing feedback — when several problems interact, put them all in one detailed message so Claude can solve them together; when they’re independent, fix them one at a time. Batching interacting issues avoids fixing one in a way that breaks another; sequencing independent ones keeps each change small and reviewable.

The exam-ready judgment across these: reach for concrete examples and failing tests over more adjectives. Use the interview pattern when the requirements are underspecified. And let whether the problems interact decide whether you batch or sequence the feedback.

Final thoughts

Slash commands are the workflows you invoke (.claude/commands/, project or user scope). Skills are the capabilities Claude invokes on its own (.claude/skills/SKILL.md), with context: fork isolating verbose output, allowed-tools restricting what the skill can do, and argument-hint prompting for inputs. Universal standards go in CLAUDE.md; task-specific workflows go in skills. And refinement is steering with concreteness — examples, failing tests, and the interview pattern — batching feedback when problems interact and sequencing it when they don’t. The exam rewards knowing which mechanism fits, not just that each exists.

Next: plan mode and CI/CD — when to plan before executing, and how Claude Code runs non-interactively in a pipeline.