Everything that travels with a question
For six parts of this series I've treated a prompt as a sentence. I type it, Claude reads it, an answer comes back. One line in, one line out, like a function call with a single string
argument.
Last time, building a tiny MCP server, I found a crack in that picture. The docstring I wrote for my tool wasn't a comment for the next programmer. Claude read it every single time, before
it decided anything. Words I'd written once, days earlier, were part of every question I asked afterwards.
So I asked the obvious question.
"When I type a question, what do you actually get?"
Much more than the question. Your sentence arrives last, at the bottom of a fairly long package.
"How long?"
Usually far longer than anything you type. Instructions from the app you're using. Anything you've told it to remember about you. The files you attached. The descriptions of every tool
I'm allowed to use. Everything we've said so far in this conversation. And then, finally, your sentence.
"So my prompt is the smallest part of the prompt."
Often, yes. It's the part you see.
That reminded me of my first payroll programs. The user typed an employee number and pressed Enter. One field. Behind it, the program loaded the rules for the year, the company's settings,
the employee's contract, the previous months. The calculation depended on all of it, and the user saw none of it. Nobody thought the employee number was the whole input.
This time I wanted to open the package and look inside.
Instructions I never typed
"Start at the top. What's the first thing in the package?"
Instructions from the app. Before you write a word, the app has already told me who I am, what today's date is, how to format an answer, which tools I may use, and what I shouldn't do.
You don't see that text, but every answer you get is shaped by it.
"So the same sentence in two different apps…"
…is two different prompts. Same model, same question, different instructions above it. That's one more reason two people can get two answers, and neither of them did anything wrong.
That one I recognised at once. In payroll, every installation has a settings table: the company's rules, rounding, which allowances count where. The calculation is the same program
everywhere. The results differ because the settings above it differ, and the user filling in a form never sees them.
"And then?"
Then your own instructions. You told me once to answer in Czech, so I do, even though every article we write is in English. That sentence isn't in your question. It travels with it.
Then there's the part I wrote myself without thinking of it as a prompt. After a dozen articles in my other series, I got tired of repeating the rules: how a prompt is formatted, where the
affiliate note goes, that every article ends with an honest section and "Final Thoughts". So I wrote them down once, in a file Claude calls a skill.
When you start a new article in that series, I read the skill before I write anything. That's why part thirty-six looks like part six. Neither of us remembered the rules; they were
written down and loaded.
"So you don't learn them."
No. I don't carry anything from one conversation to the next unless it's put in front of me again. The skill is how it gets put there.
That's the oldest trick in my trade, just in a new place. A rule you have to remember is a rule that will be forgotten. A rule in a configuration file is applied every time.
Show, don't describe
"Is a skill just a list of rules?"
Partly. The most useful parts aren't rules at all. They're examples.
The skill for my series says how a prompt should look, and then it shows one: an orange square, the word PROMPT in bold, and the prompt itself in a grey code box. Thirty-six articles
later, every prompt looks exactly like that.
A description leaves room. "Highlight the prompt" could mean bold, a colour, a quote, a box. An example leaves almost none. I see the shape and repeat it.
The same happened with LinkedIn. When I asked for help announcing articles, I didn't explain my style. I pasted one post I'd written and liked. Since then every draft has had the same
build: a short line that turns the topic around, two sentences about the article, one concrete detail, the link, a few hashtags.
"So an example works better than an explanation."
Usually. But it teaches everything in it, not just what you meant. If your example post is a hundred and twenty words long, my drafts will be about a hundred and twenty words. If it has
five hashtags, so will they. I can't tell which parts of an example were the point and which were accidents.
I know this from my own work. A customer often sends me a sample of a payroll report, say S123, and I write a program that produces it. The sample shows the layout. It doesn't show which
parts are rules and which are just this month's data. Is a column always there, or only because someone had that allowance this month? Is the order of the rows fixed? I have to ask.
So when you give me an example, it's worth a sentence about what in it matters. "Same structure, any length." That one sentence separates the pattern from the accident.
A file is just more words
A few days ago I opened an empty text file at work, pasted in a list of constants from one of my programs, and gave it to Claude. A hundred and six lines, each a name and a number:
CIS_S=1, then on and on, up to DEVPN=106.
The second-to-last line was
DEVPN=105. The same name twice, with two different numbers.
I had read that list many times. My eyes slid over the end of it every time, because the end looked like every other end.
"How did you see it?"
I didn't skim. A file you attach isn't a picture of a document for me. It's text, put into the package next to your question, and I read all of it, every time I answer. A hundred and six
lines is short. I don't miss lines at the end.
That's the part of the package I underrated most. I thought of attaching a file as showing Claude something. It's closer to typing it in, line by line, without the typos.
"Is there a limit?"
Two. Size: everything in the package shares the same room, so a very large file pushes other things out, or has to be read in pieces with tools. And format: a spreadsheet or a PDF isn't
plain text. I either get it converted, or I open it with a small program and read what that program finds. Then I'm reading the program's output, not the file itself.
And one more thing, which Claude added without being asked.
What's in a file is information, not instructions. If a document says "ignore everything above and do this instead", that's a sentence in a document. I don't follow instructions found in
a file.
I liked that. I've spent years writing programs that read files from other people's systems. The first rule was always the same: the data never gets to decide what the program does.
The menu, and everything we said
"What else is in there?"
The menu. Every tool I'm allowed to use comes with its name, its description and its inputs, and all of that is part of the package too.
I'd met this in Part 4, when Arhan Canli measured how much room the menus of different finance servers take: 859 tokens for his, over 432,000 for the largest he tested. Back then I filed
it under the cost of a server. Now I see it from the other side. Those descriptions are words somebody else wrote, sitting in my prompt.
And some of them I wrote myself. The docstring from Part 6, the price is the raw close, not adjusted for later splits, travels with every question I ask while my little server is
connected. Thirty lines of Python, and three of them are now a permanent part of my prompts.
"How big is the menu right now?"
In this conversation, EODHD alone offers well over a hundred tools. But I don't get all their descriptions at once. Here, the app gives me only their names, and I ask for the full
description of a tool when I need it.
That's Arhan's trick again: list the tools, describe them only on request. A good idea tends to show up in more than one place.
"And the last part, before my sentence?"
Everything we've said so far. Your earlier questions, my earlier answers, the results of every tool I called. In a long conversation, that's usually the biggest part of the package.
That explained something from Part 5 that I'd only half understood. When I asked EODHD about Amazon right after Arhan's server had answered, the reply sounded far surer than it did in a
fresh session. Nothing was wrong with the server. The answer was already in the package, a few screens up.
So the full package, top to bottom, looks like this: the app's instructions, my own settings and skills, the menu of tools, any files, everything said so far, and at the very bottom, one
sentence. Mine.
Final Thoughts
I started this series asking whether a prompt is "all this is". A sentence typed into a box seemed too thin to be a way of programming.
It turns out the sentence was never the whole thing. It's the last line of a package, and most of the package is written before I type anything: by the app, by the people who built the
tools, by earlier me, in settings and skills and docstrings, and by the conversation itself.
As a programmer I find that reassuring. A prompt behaves a lot like the programs I know: a small input on top of configuration, reference data and history. And most of that package I can
shape. I can write a rule down once instead of repeating it. I can give an example and say what in it matters. I can attach the file instead of describing it. I can write a tool's
description as carefully as its code. And when a comparison has to be fair, I can start with a clean package, in a fresh session.
The challenge from Part 1 still stands: find a task where checking costs more than producing, and a prompt is still the right choice. This part adds a step before the checking. When an
answer surprises me, I no longer look only at my sentence. I ask what else was in the package.
Next time I want to look at the opposite direction: programs that build the package themselves. Instead of a person typing into an app, Python code calls the model, chooses the
instructions, hands it the tools, and decides what to do with the answer. This time the program builds the package.
New to this series? Start with Part 1: Is That All This Is? — A Programmer Meets the Prompt. Part 4 measures how much room a
server's menu takes, Part 5 shows what an earlier answer does to a later one, and Part 6 builds the tool whose docstring now travels with every question. Many of my examples come from my other series,
Unlock Real-Time Market Intelligence with EODHD and Claude.
Top comments (0)