Write a Claude Context Brief You Never Retype Again
Most people start every new chat the same way: a sentence or two of background, then the actual request. Your role, your team, what you're working on this quarter, all retyped from memory, slightly differently each time. It works, but it's the same setup cost paid over and over for information that hasn't actually changed.
Tip
A context brief isn't a longer prompt. It's the handful of facts that are true no matter what you're asking that day, written once so you stop re-deciding how to phrase them.
If you're retyping the same three sentences every week, they belong in a brief, not in your memory.
What actually belongs in a brief
A context brief is short on purpose. It holds the facts that stay true across many different requests, not the details specific to today's task. Mixing the two is what makes people give up on the idea after one try, since a brief that tries to cover everything becomes just as much work to maintain as retyping.
Your role and team, specifically enough to matter
Standard terms or shorthand your work uses that Claude wouldn't otherwise know
Current priorities or context that shape how you want most things approached right now
What doesn't belong: anything specific to one task. The deadline for this particular email, the audience for this particular slide, the exact number in this particular report. That detail changes every time, so it belongs in the prompt itself, not in a brief you'd have to edit constantly to keep accurate.
A common mistake is writing something closer to a full team bio than a brief: every direct report's name, every past project, every tool the team has ever used. None of that changes how Claude should approach a typical request from you, so none of it earns a place in something meant to stay short enough to actually reuse. If a fact wouldn't change how Claude handles most of your requests, it belongs in a document somewhere else, not here.
Here's my context: I'm a operations lead at a 40-person logistics company. My team handles vendor relationships and internal process documentation. We use "SOP" for standard operating procedure and "the Q3 push" to refer to our current warehouse consolidation project. Keep this in mind for the rest of this conversation.
”Notice what's missing from that brief: no mention of today's specific task. That comes next, in the actual request, once the background is established.
Where a brief actually lives
For a one-off need, pasting the brief at the start of a chat is enough. It costs you one paste instead of scattered fragments across ten separate sentences, and Claude has it for the rest of that conversation.
For work that spans many chats over weeks or months, retyping the same brief at the start of every new chat defeats the purpose. That's exactly the gap a Project closes: store the brief once as a Project's persistent instructions, and every chat you start inside it already has that context, with nothing to paste at all. If you haven't set one up yet, the article on working with Projects in this path covers exactly when that's worth doing.
The dividing line is frequency, not importance. A brief for a single high-stakes presentation still only needs pasting once, at the start of that one chat. A brief for an ongoing role, one you'd otherwise retype dozens of times over a quarter, is what actually justifies the setup cost of a Project.
Inside Claude Tutorial
Writing something once so you stop repeating it is a transferable habit.
A reusable context brief is one version of a pattern that shows up everywhere: write the stable part once, reuse it, and only ever touch the part that actually changes. The app has a full lesson on this habit, with practice that carries over well beyond writing a brief.
Testing it, and updating it once it goes stale
A brief you write once and never revisit slowly drifts from reality. Your team changes, a project wraps up, the shorthand you used six months ago stops meaning anything to anyone including you. Treat a brief as a living document, not a one-time setup task.
- 1
Write a short first version
Three to five sentences. If it's longer than that, it's drifting into task-specific detail that belongs in individual prompts instead.
- 2
Test it on a real request
Paste the brief, then ask for something you'd normally ask for anyway. Check whether the answer actually reflects the context, not just whether Claude acknowledged reading it.
- 3
Revise anything that didn't land
If a term didn't get picked up correctly, or a priority didn't shape the answer the way you expected, rewrite that one line rather than the whole brief.
- 4
Revisit it when something real changes
A new role, a wrapped-up project, a shorthand nobody uses anymore. Treat those as the trigger to update it, not a fixed schedule.
Based on the context I gave you above, does anything about my role or the Q3 push seem outdated or missing something that would change how you'd approach a typical request from me? Ask me directly if something's unclear.
”A brief that's actually working fades into the background. You stop noticing you're using it, which is the whole point: the setup cost only had to be paid once.
Continue reading
- Working With Projects: Giving Claude Context That Sticks Around: where a brief like this belongs once your work spans more than a handful of chats.
- Getting Started with Claude: the earlier habit of keeping a short reusable instruction set, which this article turns into something more durable.