Slash Commands, Skills, and Iterative Refinement

Two more pieces of Domain 3: the reusable workflows you define (Task 3.2 — slash commands and skills) and the techniques for steering Claude toward the result you want (Task 3.5 — iterative refinement). The first is configuration I can confirm against the live tool; the second is a set of prompting patterns whose effectiveness is model-dependent, so those claims carry a ⚠️ for the key-based pass. What’s not model-dependent — and heavily tested — is knowing which mechanism to reach for.

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 distinction is the exam-ready one: 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.

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 — a full codebase analysis, an exploratory brainstorm — would flood the main session’s context if it ran inline. 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.

Iterative refinement: steering, not one-shotting

Task 3.5 is about the techniques that get Claude from a first attempt to the output you actually want. The unifying insight is that prose is interpreted inconsistently, and concreteness fixes it. (⚠️ these techniques’ effectiveness is a model-behavior claim, pending the key pass; the patterns are the exam content.)

• 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.