“Give it more context” means three different things

“Give it more context” is advice I have handed out plenty of times, and I have taken it plenty of times. What I noticed eventually is that I meant three different things by it depending on the day, and nobody hearing it had any way to tell which one I was talking about.

Separating the word into three has done more for the quality of what I get back than any prompt technique I have tried. The win is not technical. Nothing stops all of it living in one file. The three parts behave differently, they age at completely different speeds, and they belong in different conversations, and once they sit apart you can see which is which.

What does context actually mean here?

Three separate things. Instructions are how you want the work done. Context is what is true about your business right now. Knowledge is what stays true across every project you touch. Kept in one file they blur together, and the file grows long enough that the part you actually needed is the part that gets skimmed.

• Instructions: tone, formatting, what to never do, how to hand work back. Short and bossy. This is the one that should be read every single time.
• Context: the business, the offer, who you sell to, what you are trying to hit this quarter, which projects are live, the actual numbers. True today, not necessarily true in March.
• Knowledge: conversion, test learnings, what a decent SaaS page does, notes out of books, the psychology of why people hesitate. Earned slowly, thrown away almost never.

Why keep them in separate folders?

Because you can then see, without opening anything, which part needs constant maintenance and which part you wrote once and can leave alone. Instructions barely move. Knowledge grows. Context needs a look every few weeks or it starts lying to you. One folder hides all of that.

The second reason is that they are not all wanted at once. A question about a headline does not need your buyer profile, your revenue numbers and four years of test learnings loaded alongside it. When the three sit in separate folders, a skill can say read this one, skip that one, in a single line. When they sit in one file, it is all or nothing every time.

Which part goes stale, and what does that cost?

The middle one, every time. Positioning you wrote a while back, an ICP that moved, a project that finished in spring, a number from last year. None of it announces itself as old. It reads as true, the assistant treats it as true, and the answer comes back sounding completely certain about a version of your business that stopped existing months ago.

My main instructions file now carries a line saying the project files might be out of date and to go check the live source first. Slightly silly thing to have to write down for yourself. It took a few confidently wrong answers to get there.

The project files are a starting point, not the answer. Check the live version before you rely on them.

Does this actually change the output?

Two cases where it made an obvious difference. The first was a website scoring tool I built. Early versions took a URL and gave back confident, fairly random feedback, round after round. What fixed it was feeding in what I already knew about what a good SaaS page does and, just as importantly, what to ignore. Then the scoring started making sense.

The second is A/B test ideas. Asked cold, I get button colours and headline swaps, the same list anyone gets. With old test learnings, the business context and a real description of who we sell to sitting behind the question, I get ideas that stand a chance of moving something. Nothing about the model changed in between.

What goes in each folder?

Markdown files, and boring ones. There is nothing clever in mine. One file per live project, a business file, and a knowledge folder holding years of notes on conversion, web, marketing and testing. The shape below is the whole idea, and it is worth copying before you improve on it.

1your-context/
2├── CLAUDE.md          instructions: how you want the work done
3├── context/           what is true right now
4│   ├── business.md    positioning, offer, who you sell to, numbers
5│   └── projects/      one file per live project
6│       └── acme.md
7└── knowledge/         what stays true across projects
8    ├── conversion.md
9    ├── test-learnings.md
10    └── messaging.md

A project file is worth a template, because the fields you forget are always the same ones. Dates on numbers, and a pointer to wherever the real answer lives.

1# Acme
2
3**Live source.** The repo, its README, the last twenty commits. Read
4these before trusting anything below.
5
6**What it is.** One paragraph a stranger would understand.
7
8**Who it is for.** The buyer, in their words rather than ours.
9
10**Where it stands.** What shipped, what is next, what is stuck.
11
12**The numbers.** Traffic, conversion, revenue, each one carrying the
13month it came from. A number without a date ages into a lie.
14
15_Updated: 2026-09-03_

How does the assistant know which folder to read?

You tell it once, in the instructions file, and never again. Four lines are enough. The point is that the rule lives in the one file that always gets read, so every skill and every chat inherits it without you repeating yourself.

1# How to use this folder
2
3- Read this file every time. It is short on purpose.
4- Read context/ when the task touches a live project, an offer or a
5  number. Treat every file in there as out of date until you have
6  checked the live source.
7- Read knowledge/ when the task needs judgement rather than facts.
8  A test idea, a page critique, a messaging call.
9- Do not load all three for a one-line question.

How much of this should you build?

Less than the internet suggests. You will see packs of fifty skills, immaculate instruction files, whole agent setups, and it is easy to come away feeling yours is embarrassingly plain. You have no idea what problem any of those solved for the person who built them. Their context is not yours.

• Not every recurring task needs to become a skill. Some belong in the instructions file as one rule. Some are genuinely faster done by hand.
• Build a skill after you have done the job manually a few times and know what it actually needs, not before.
• Keep iterating on the ones you reach for. The first version is rarely right, and it is still worth writing.
• Keep the whole thing light, so that when the models change again you can adjust it in an afternoon rather than defending it.

Writing all of this down takes evenings I would rather spend building, so I do it in small pieces, whenever something comes up that I know I will want back later. Nothing about the split is finished, and I will probably move things around again.

Even with none of it in place, “give it more context” is still the best advice going. I just know which one I mean now.