Project Contexts: Stop Re-Explaining Your Project

TL;DR: An AI project context is a background document you write once, scoped to one piece of ongoing work, that loads into every chat inside that scope automatically. Set it up on ChatGPT's or Claude's native project feature if you only use one platform, or in a portable context library if your work spans tools. This post covers where to click on each, what to actually write, and what never belongs in it.

You already know the tax. New chat, and before you can ask the actual question, you're retyping what the product does, who it's for, and the constraint that keeps tripping the model up. Do that four times a day and it's not a rounding error, it's a second job. A project context exists to make that briefing happen exactly once.

Why do you keep re-explaining the same project?

Because a fresh chat has no idea what happened in the last one, and neither ChatGPT nor Claude assumes you want it to unless you've told the tool to scope your work into something durable. Every new conversation starts from the same blank state your first message to that product ever did. That's true even if you asked the model the same three background questions yesterday.

The cost compounds faster than it looks, because it isn't only the minutes spent retyping. It's what happens when you get impatient and skip the briefing instead. A prompt written without the background produces an answer that's structurally fine and specific to nobody: a PRD with goals that could belong to any product, marketing copy that reads like it was written for a category rather than a company, a debugging suggestion that ignores a constraint you mentioned three chats ago and never wrote down. The output isn't wrong exactly. It's generic in a way that costs you a second pass to fix, which is the same tax as retyping the background, just deferred and harder to notice.

The fix isn't a better memory, at least not primarily. It's a place to put the background once, attached to the work rather than to a single conversation, so the model has it before you type a word. That's what a project context is for, and it's a different thing from the model quietly remembering you, which is a separate mechanism with its own rules, covered in Context vs Memory vs Custom Instructions.

How do you set up a project context on ChatGPT?

Open the Projects view and create one. OpenAI's own documentation frames the decision plainly: "Create a project when work will continue over time, produce more than one output, or depend on the same files and sources." If the task is a one-off, skip it; a project is for work you'll return to.

Once it exists, OpenAI's own documentation describes the layout as a Chats section that lists your project chats, plus a Sources section for uploaded files and connected context. Add your background as project instructions, and drop any reference material, briefs, or existing docs into Sources. The part people skip: "Project instructions apply across its chats." That's only true if you actually start new chats from inside the project. A chat you begin from the regular composer, outside the project, never sees any of it.

How do you set up a project context on Claude?

Claude's version is a project, too, and it's available further down the pricing ladder than most people assume. Anthropic's own documentation is direct: "Free users can create a maximum of five projects." Create one, give it a name, and you'll find two separate places to put your background: project instructions (a text field for guidance and requirements) and project knowledge (files and pasted material Claude treats as reference).

Anthropic's help pages are genuinely inconsistent about whether project instructions specifically require a paid plan, contradicting themselves within a single article. Don't take either version at face value: try creating a project and adding instructions on your own account, and go by what actually happens rather than by what either sentence claims.

Practically, put your background paragraph in project instructions and reserve project knowledge for things you'd actually want quoted verbatim: a style guide, a product spec, existing docs. Mixing the two, dumping a long PDF into instructions or a one-line summary into knowledge, doesn't break anything, but it makes the project harder to maintain once it's the only place either lives.

A quick reference for where each option actually lives:

How do you make one project context work across every AI tool you use?

Neither ChatGPT's projects nor Claude's carry their background into the other platform, or into Gemini. If your actual week is single-platform, that's fine, use the native feature and stop here. If it isn't, rebuilding the same background twice or three times is exactly the re-explaining this post is about, just moved up a level from "every chat" to "every platform."

A portable context library solves that by living outside all three apps. Prompt Architects' Personal Context sits in the extension sidebar you already use inside ChatGPT, Claude, and Gemini: write a context entry once, then select it when you generate a prompt in whichever tool you opened that day. It's not available on the free tier; Pro includes a published 8,000-character library, and Advanced and Team raise that to 15,000. Unlike a native project, nothing about it is tied to one vendor's app, so switching tools mid-project doesn't mean starting the briefing over.

Gemini's version doesn't map onto "projects" quite as cleanly. The closest equivalent is a Gem: a saved set of instructions you create once and reuse, scoped to that Gem rather than to a project the way ChatGPT and Claude use the term. Google publishes an age requirement for creating Gems but not a plan requirement or a count limit, so don't assume a free account is locked out before you've actually tried. If you're setting one up, our Gemini Gem templates has ready-to-adapt starting instructions rather than a blank field.

What should actually go in a project context?

Keep it to what a new teammate would need in their first five minutes, not a design document. A working shape:

PROJECT CONTEXT

Product / project: [one sentence — what it is]
Audience: [who it's for — role, company type, what they're trying to do]
Problem it solves: [two to three sentences]
Current stage: [where this is right now]
Key constraint: [the one thing the model keeps getting wrong without this]
This period's goal: [what "done" looks like right now]
Do not assume: [the top one or two things the model should never invent]

Every line should earn its place the same way it would in a written brief: if a competent person could infer it by reading the actual work, it doesn't need to be here. The line that earns the most is usually "do not assume," because a model filling a gap with a plausible guess is far more common, and far more expensive to catch, than a model asking a clarifying question.

Filled in, for a small B2B tool, it reads short enough to actually maintain:

PROJECT CONTEXT

Product / project: Invoice reminders app for freelance consultants.
Audience: Solo consultants and small agencies who bill hourly, mostly
  non-technical, currently chasing late payments by hand over email.
Problem it solves: Consultants lose income to invoices they forget to
  chase. The app auto-sends polite reminders on a schedule they set once.
Current stage: Private beta, 40 users, still adding payment integrations.
Key constraint: Never suggest a feature that requires the client to
  install anything. Everything runs from the consultant's side only.
This period's goal: Get 10 of the 40 beta users to connect a payment
  provider, not just draft reminders.
Do not assume: The user has technical staff, or that "the client" means
  a company rather than an individual paying a freelancer.

Notice what isn't in there: no tech stack, no roadmap dates, no list of every feature. A model given this can write an onboarding email, a feature announcement, or a support reply that already sounds like it understands who's using the product, without you explaining any of it first.

The exact shape shifts by who's writing it. A product manager's version leans on audience and success metric, covered in more depth in Keep Product Context in Every AI Chat; an agency or freelancer juggling several clients needs one context per client rather than one shared version, the approach in One Prompt System, Ten Clients.

What mistakes actually break a project context?

Four show up over and over, and none of them are exotic.

Writing it like a spec instead of a briefing. A project context isn't the place for every requirement, edge case, and future feature. It's the five-minute version. If it's long enough that you'd hesitate to read it before every chat, it's too long for the model to weigh properly either.

Never starting chats from inside the project. This is the single most common way a ChatGPT or Claude project context "stops working." It didn't stop working; the chat that ignored it was never connected to it. If you're not sure, check where the new chat button you clicked actually lives.

Writing what you wish were true. A context that claims the API is fully documented when half of it isn't, or that the target user is enterprise when you're actually selling to solo freelancers, doesn't just fail to help. It actively misleads the model into producing output calibrated to a product that doesn't exist.

Treating it as permanent. The most expensive version of staleness is a "do not assume" line nobody revisits after the assumption stopped being risky, sitting next to a "key constraint" that got resolved months ago. Both cost you the same as writing nothing, and the second one costs more, because wrong information reads as more confident than no information.

How do you keep a project context from going stale?

The same way you'd keep any shared document from going stale: revisit it when the thing it describes changes, not on a schedule. A constraint that got resolved two sprints ago and is still sitting in your project instructions isn't harmless. It's actively wrong information the model now treats as current, which is a worse failure mode than having written nothing at all.

If you've made a substantial edit, start your next chat fresh rather than continuing an old one. Platforms differ on exactly when an edited instruction takes effect for a conversation already in progress, and the safest habit, regardless of which platform you're on, is to let a new chat pick up the new version rather than guess.

None of this requires a new tool if you only ever work in one AI platform: ChatGPT's and Claude's own project features do the job. The moment your actual week involves more than one, the choice is between rebuilding the same five sentences twice, or writing them once somewhere that follows you. Pick whichever matches how you actually work, not how the marketing page for either platform assumes you work.