ChatGPT Projects Best Practices: Files, Instructions and Memory

A ChatGPT project works best when it covers one body of work, holds only the files that most of its chats need, has short instructions that override your general ones for a reason, and uses a memory setting you picked rather than the one you were given. The decision people skip is memory: default memory lets a project draw on the rest of your ChatGPT history, project-only memory walls it off, and a shared project is always walled off. Choose it when you create the project, then write back into the project whatever its chats settle, because a saved note is something you can read and correct and memory is not.

This is the ChatGPT version of Claude Projects best practices. How the two products differ is in Claude Projects vs ChatGPT Projects, so it is not repeated here.

Scope it to one body of work

OpenAI’s guide to projects and chats↗ (opens in a new tab) gives the test: create a project when the work will continue over time, produce more than one output, or depend on the same files and sources. It adds the habit that keeps a project readable: start a separate chat for each distinct outcome, so each chat stays focused while the project holds what they share.

• Good scopes: one client, one product launch, one course, one recurring report.
• Too broad: “Work”, “2026”, “Misc”. The instructions start to contradict each other and the files stop being relevant to most chats.
• Too narrow: one question. That is a chat.
• Name chats for their outcome, such as “Pricing page draft v2”, so the project’s chat list reads like a log.

Choose the memory setting on purpose

Each project has one of two settings, chosen when you create it and changeable later from Project settings, with changes taking a few hours to apply. OpenAI’s projects guide in the Academy↗ (opens in a new tab) describes project-only memory as the isolated one: your saved memories are not referenced, and chats cannot reference conversations outside the project. OpenAI’s pages differ on which plans have it: that Academy guide lists only Business and Enterprise, while the help centre also describes it for individual plans, and on Business and Enterprise only when Memory is on for both the workspace and your account.

• Default memory: your saved memories apply, and chats draw on other chats in the project. On most plans they can also draw on conversations outside it, and be drawn on in turn; on Enterprise and Edu the project stays contained.
• Project-only memory: no saved memories, no conversations from outside, and nothing from inside leaks out. The help centre notes one cost: ChatGPT Work is not available in a project set this way.
• Shared projects: always project-only, and a project cannot go back to default memory once it has been shared.

The rule of thumb: project-only for client work, anything confidential and anything you plan to share; default for personal projects where your general context genuinely helps. There is no list of project memories to review, so if one chat went wrong and you do not want it influencing the rest, delete it or move it out.

Keep the files few and current

Files are the project’s reference shelf: PDFs, spreadsheets, documents, images or pasted text, and in a private project, links to Google Drive files and folders or Slack channels. The number you can add depends on the plan, and only ten upload at a time. Treat that limit as a feature.

• One current version of each document. Two drafts of the same spec give two answers to choose from.
• Names that say what the file is: “brand-guide-2026.pdf”, not “final (3).pdf”. ChatGPT warns on a duplicate name; choose Skip unless you mean to keep both.
• Leave out what one chat needs. Attach it to that chat instead.
• Prefer a linked Google Drive folder to re-uploading a document that changes weekly, so the project works from the live copy.
• In a shared project, deleting a file removes it for everyone. Say so before you tidy up.

Write instructions that override for a reason

Project instructions live under the ••• menu, Project settings. They apply only inside the project and override your global custom instructions, which is the point: the project is where your usual tone, format or role is wrong. Write rules, not background; put the background in a file and point to it by name.

Purpose: this project supports <client or work>, <one line on what we deliver>.

Audience: <who reads what you draft>. Write for them: <plain English / technical>, British spelling.

Sources: "<file name>" is the current source of truth. If a request contradicts it, say so before answering.

Rules:
- <A checkable rule>, because <one-clause reason>.
- Prices are always <ex VAT / in EUR>, because <reason>.
- When you are unsure what was agreed, say so. Do not fill the gap with a guess.

Output: <format, length, headings>. End drafts with a one-line summary of what we are asking for.

Decisions: read "decisions.md" before answering questions about scope or dates.

• Keep it short. Five rules that always apply beat thirty that sometimes do.
• Make each rule checkable. “Be concise” is a hope; “under 150 words unless I ask for more” is a rule.
• In a shared project, write for teammates as well as ChatGPT. The instructions are how everyone gets the same behaviour.
• When a rule changes, rewrite it. A new line contradicting an old one leaves ChatGPT to choose.

Save conclusions back into the project

When a chat produces something worth keeping (a decision, a summary, a corrected fact), open the message menu and save it to the project’s sources. Better still, keep one running file such as “decisions.md”, newest first, with the date and who agreed, and replace it when it changes. Memory may carry some of this forward on its own, but you cannot see or edit what it kept. A source file you can.

Share with the right access

Projects can be shared on every plan, from Free to Enterprise. Members get chat access, to see and use the project’s chats, files and instructions, or edit access, which also lets them change instructions, add and remove files and invite others. An owner can limit the project to invited people or open it to anyone signed in to ChatGPT who has the link.

• Members see the project’s chats. Anything typed in a shared project is visible to its members, so keep private drafting out of it.
• Give edit access to the people who own the instructions and files, and chat access to everyone else.
• Use invite-only for anything confidential, and check the member list under Share from time to time.
• Members can branch a colleague’s chat to try another direction without changing the original.

Connectors: use them, do not copy them

Connected apps work in project chats from the tools menu, and ChatGPT may ask before an app searches outside the project. Use an app for data that changes, such as today’s tickets or this week’s calendar, and project files for material that does not. One instruction line settles which to trust: “for ticket status use the app, not the uploaded export”. OpenAI’s plugins guide↗ (opens in a new tab) covers installing them, and what apps can reach, and who controls them, is in ChatGPT connectors and apps.

Keep it current

• Replace a superseded file the same day. Stale files are worse than missing ones, because they are used with confidence.
• Reread the instructions monthly and delete the rules nobody needed.
• Correcting ChatGPT the same way twice means the correction belongs in the instructions.
• Delete chats that went wrong, so memory stops drawing on them.
• When the work ends and you no longer need it, delete the project. Deleting removes its chats, instructions and files stored only in the project; files saved separately in Library stay.

When the project turns into a task list

The sign a project has outgrown itself: the file you update most is a list of things to do. A file cannot say who is on which item or record who changed it, and in a shared project that matters. That list belongs on a board. fenbs is a small one, with tasks as features, enhancements or bugs in lanes To Do, Next Up, In Progress and Completed, and ChatGPT can connect to it as a developer-mode app (a custom MCP server) where your plan offers developer mode, working under your role with each change recorded in History under its name. See ChatGPT and fenbs.