Module 14 — Giving the Brain Hands: Tools, Prompts, Context & Skills

🎯 Goal: Understand the four ideas that turn a frozen, isolated LLM into something that can actually do your work: tools, prompt engineering, context, and skills. ⏱️ Time: ~30 min of reading. No hands-on.

Module 13 left us with a brilliant brain sealed in a room — no live knowledge, no access to your files. This module is how it reaches out and gets things done.

Four additions turn the sealed brain into Claude Code: tools (hands to act), a good prompt (a clear brief), context (the desk it works at), and skills (playbooks it loads when they fit).

1. Tools — how the brain touches the real world

On its own, an LLM can only produce text. It can't actually open report.pdf, check today's date, search the web, or run a program. Those require tools.

A tool is a capability you hand the model: a file-reader, a web-search, a calculator, a "run this terminal command" button. Here's the clever part — the model can ask to use a tool. Mid-answer it can essentially say: "I need to use the file-reader on report.pdf." The surrounding software runs that tool, hands the result back, and the model continues with the new information in hand.

Analogy: The brain-in-a-room can't leave, but it can write notes and slip them under the door: "Please fetch the contents of report.pdf." An assistant outside (the software) does it and passes the contents back in. The model decides when it needs a tool, like a chef calling for a specific utensil.

This is the whole trick behind Claude Code: Claude (the frozen brain) is wrapped in software that gives it tools to read/write your files and run commands. The intelligence is the model; the hands are the tools. Neither is useful alone.

2. Prompt engineering — how you ask matters

A prompt is just what you type to the model. Prompt engineering is the skill of asking well. Same model, very different results depending on how you phrase the request — exactly like briefing a new assistant: vague brief, vague work; clear brief with context and examples, great work.

You already met the practical version in Module 07. The principles, restated as the craft:

Be specific about the outcome. "Summarize this" → "Summarize this in 5 bullet points a manager could skim in 20 seconds."
Give context only you have. "The effective date is the one labeled 'Effective:', not the print date at the bottom."
Show an example of what good looks like when you can.
State the format you want (a table, a sentence, a checklist).
Break big asks into steps so misunderstandings surface early.

Analogy: A new assistant who's never seen your work. Hand them a sticky note that says "fix the report" and you'll get a guess. Hand them clear instructions, an example, and the relevant file, and you'll get what you wanted.

3. Context — the model's desk (and why size matters)

Here's a subtle but crucial idea. The model has no memory — so how does it "know" what you said three messages ago, or what was in the file it just read?

Everything the model can currently "see" — your instructions, the conversation so far, the files it has read, the results tools handed back — is called the context. Think of it as the model's working desk: every relevant paper laid out in front of it for this response. It re-reads the whole desk each time it predicts the next chunk of text.

But the desk has a fixed size — the context window. It can only hold so much at once (large, but not unlimited). This has real consequences you should feel:

When the desk fills up, things fall off. Stuff a very long conversation or a huge file in, and the earliest material gets pushed out — the model effectively "forgets" the start.
Clutter hurts quality. A desk piled with irrelevant papers makes it harder to focus on the ones that matter — and it's slower and costs more.

This is why Module 11 told you to keep one task per conversation and use /clear between unrelated jobs: you're keeping the desk tidy so the model works on exactly the right papers.

The context is the model's desk — your instructions, the chat so far, and everything it has read, laid out for this one reply. The desk has a fixed size, so a tidy desk means better, faster, cheaper answers — and an overstuffed one means the earliest papers slide off.

4. Context engineering — the evolution beyond prompting

Prompt engineering is about crafting the question. Context engineering is the bigger, newer idea: deliberately curating everything on the desk — which files to put in front of the model, how much conversation history to keep, which tools to make available — so it has exactly what it needs and not a pile of junk.

Why this evolved out of prompt engineering: once models got tools, the model could pull in its own information (read files, search, run commands). The job shifted from "write one perfect prompt" to "manage the flow of information on the desk over a whole task." A perfectly worded prompt buried under 50 irrelevant files will still get a mediocre answer.

Analogy: Prompt engineering is asking a great question. Context engineering is being a great chief-of-staff — making sure the expert has the right three documents open, the relevant history at hand, and nothing distracting, before they start. For complex work, the second skill matters more.

The everyday takeaways for you are simple and you've already been taught them: keep context focused (one task per chat, /clear often), give the model the specific files it needs (not your whole drive), and use a CLAUDE.md to keep important standing facts always on the desk without re-typing them.

5. Skills — reusable expertise the model loads on demand

Imagine you keep asking the model to do a specialized task — say, build a polished slideshow — and every time you have to re-explain all the best practices. Tedious. A skill solves this: it's a saved bundle of instructions (and sometimes helper tools) for a particular kind of task, which the model pulls in only when it's relevant.

Analogy: A binder of specialist playbooks on a shelf. The model glances at the labels, and when a task matches — "ah, this is a PDF job" — it pulls that playbook off the shelf and follows it. The playbooks it doesn't need stay on the shelf, keeping the desk uncluttered (good context engineering!).

A skill is a saved playbook for one kind of job. The model reads the labels, and when your task matches — "ah, a PDF job" — it pulls just that playbook and follows it. The rest stay on the shelf, so the desk stays clear.

Claude Code ships with skills for common jobs (working with PDFs, Excel spreadsheets, Word docs, PowerPoint, and more). You usually don't invoke them by hand — when your task matches, the right skill loads automatically. You can also create your own for the specialized tasks you repeat, so your hard-won "how I like this done" becomes a reusable playbook.

How you use them, practically:

Mostly, do nothing — the relevant skill loads when your task fits.
Lean into them — if you have a repetitive specialized workflow, ask Claude Code to capture it as a skill (or a custom command), so next time it's one step.

✅ Takeaways

Tools let the frozen brain act on the real world; the model asks to use them and works with what they return.
Prompt engineering = asking well (specific, with context and examples).
Context is the model's desk — everything it can currently see. The desk has a fixed size; keep it focused, because clutter and overflow hurt.
Context engineering is curating that desk over a whole task — the skill that matters most once tools are in play.
Skills are reusable playbooks the model loads only when relevant.

Next: Module 15 — How Claude Code Works, where all of this clicks together into the tool you've been using.