How to organize your work in ChatGPT.

First, what are you trying to keep together?

You open ChatGPT to work on an article. Somewhere along the way, you ask about the headline, check a tool, rewrite an email, and think of an idea for a completely different page.

A few days later, you want to continue the article. Where was that useful bit? Which version did you like? Did you already explain the audience in this chat, or was that another one?

This is where a little structure helps.

My starting point would be simple: use a chat for one focused task, a Project for work that shares a brief and reference material, and a reusable assistant or workflow for a method you want to repeat. You can use these together. You do not have to choose one forever.

I come at this from writing, research, project work, and content operations. The question I care about is quite practical: can I come back tomorrow and understand what happens next?

That is what we are setting up here. One manageable place for the work, with enough detail to continue it. No elaborate system to maintain before you have even started.

One current detail: OpenAI documents a transition from custom GPTs to plugins. Availability varies by account and workspace. I cover both below. See the current migration guidance.

Chats, Projects, GPTs. What is the difference?

Think about the job each part is doing. The conversation, the surrounding work, and the repeatable method are three different things.

A chat is where you work through a task

For a self-contained request, I would start with an ordinary chat. Help me tighten this paragraph. Explain this spreadsheet formula. Give me questions to ask before accepting this brief.

Give the chat a clear outcome. If the conversation wanders into a different deliverable, that is a useful moment to start another one.

A Project keeps related work together

A ChatGPT Project groups related chats with uploaded files, project instructions, and connected sources. Those project instructions apply across its chats. You can keep separate conversations for separate outcomes while using the same project references. OpenAI explains Projects here.

For me, a website content Project makes sense because the audience, services, voice, and approved background keep coming up. I would not want to rewrite that whole brief every time I worked on another page.

A custom GPT carries a particular setup

Custom GPTs package instructions, reference knowledge, and available capabilities for a particular purpose. Their replacement path uses skills and plugins. Source: OpenAI's GPT migration guide.

Also, ChatGPT, a model name containing GPT, and a custom GPT are not interchangeable terms. Here, when I say a GPT, I mean the custom assistant someone configured, rather than the underlying model.

And if you see Chat and Work, that is another choice: the experience you use to do the task. Both can have chats in the same Project. It is not another filing system you need to invent. More on using ChatGPT.

Choose the smallest setup that helps

Here is how I would decide.

One question? Start a chat.

If you can explain the task with one short brief and a relevant attachment, you probably have enough to start. You can decide whether it needs a bigger home after you understand the work.

The same background keeps coming up? Use a Project.

A website, an ongoing research topic, or a client content assignment gives you several related outputs. That is where I would collect the shared brief and keep the individual tasks together.

The same instructions keep coming up? Consider a reusable workflow.

Say you keep asking for an editorial review with the same checks: reader intent, unsupported claims, vague language, internal links, and a clear next action. That repeatable review method is a candidate for a skill or an available specialist assistant.

You may need both: a Project that holds one website's material and a reusable review method that you can apply to different pieces of work. First make the method useful in a normal conversation. Then decide whether saving it would actually help.

If you are still changing the instructions every time, keep experimenting. An unfinished process does not become clearer because it has a name and an icon.

Set up one Project you will actually use

Let's use a website content Project as our example. This is a suggested setup you can adapt, rather than a claim that every account has an identical screen.

1. Name the work clearly

Use the Project creation control available in your account. Give it a name that tells you what belongs there: “My website: content” is more useful to me than “AI experiments 3.”

Decide the boundary in one sentence: this Project is for planning, drafting, and checking content for my website. My unrelated applications, travel questions, and personal admin can live elsewhere.

2. Add a small, current reference set

I would begin with an approved bio, an audience note, a short services description, a few writing samples I am comfortable using, and the current content plan. Five useful references are easier to maintain than a pile of old exports.

Add the material through the Project's source or file controls. A ChatGPT Project does not automatically give access to a folder on your computer; upload or connect the material you want it to use. Source: Projects and chats.

Keep raw notes separate from approved information. If I am still thinking through an offer, I would label it “working idea” so it is less likely to turn up in a draft as something I already sell.

3. Write instructions that make decisions easier

“Write good content” leaves quite a lot open. Describe the audience, the kind of help you want, the voice, and what to do when something is missing.

Replace the brackets before using it. Then shorten or change anything that does not fit how you work. These instructions should help you make decisions, not give you another page to admire and forget.

4. Give the first chat one outcome

Start inside the Project with something small: “Turn these rough topic notes into five article briefs for my review.” You will learn more from that real task than from polishing the setup for an hour.

Keep research, drafting, and review in separate chats

I would use three chats for one substantial article: one to establish the answer and sources, one to develop the draft, and one to review it.

Each chat gets a job. Research should leave you with a usable brief. Drafting should turn that approved brief into something readable. Review should find the things that still need attention.

There is a small habit that makes this work: hand over the actual output. I would not rely on “you know the thing we discussed” as a brief for the next conversation. Attach or paste the approved brief and identify the current draft.

Research: what can we responsibly say?

Open the important sources yourself. A neat source list is a starting point for checking, not proof that every sentence is supported. Resolve the questions that would change the argument before moving on.

Draft: turn the approved brief into a useful page

Read the draft as a person who arrived with a problem. Can they find the answer? Is the example doing useful work? Does the writing sound like something you would actually say?

Review: give the draft a proper check

A new review chat can give the task a clearer brief. It is still AI-assisted review, so I would keep my own final read and source checks. For more on what to check, read my notes on reviewing AI-assisted work.

Once the corrections are made, save the current version and record the remaining next action. “Needs a source for the second comparison” helps far more than “almost done.”

Can you bring an existing GPT into the chat?

Where available, open the GPT or mention it with @ on ChatGPT web, then send your request. See OpenAI's selection guidance.

Start with a particular task in mind. “Help me review this article against these five criteria” gives you something to evaluate. “Find me the best GPT” leaves the important part undecided.

Read what the assistant says it does, who provides it, and whether the task involves an external service. Try a small sample with information you can safely share before trusting it with more work.

Give it a brief, even if it looks specialised

Then compare the result with an ordinary chat given the same brief. Did the specialist produce more useful feedback? Did it follow the boundaries? Did it spot an issue you can verify? Keep it because it helps with the work.

Check the context instead of assuming it followed you

Do not build your workflow on the assumption that mentioning a GPT makes every Project file or earlier conversation available to it. The official selection guidance does not establish that every GPT-and-Project combination shares the same context. Supply the relevant brief, check the sources available in that conversation, and test your setup.

If the GPT you want is not available inside your current Project or device experience, use the available workflow and pass a small, approved brief between steps. You can still organise the final output with the rest of the work.

Where skills and plugins fit now

This is the bit I would check before following a tutorial that tells everyone to click “Create a GPT.” The current official guidance includes moving custom GPT workflows into plugins. Check what your account or workspace actually supports before planning around a creation screen.

A skill packages reusable instructions and supporting resources for a task. A plugin can bring skills together with tools or connections to other services. The available connections and permissions still matter. OpenAI's skills and plugins overview explains the pieces.

For this website example, I would consider saving an editorial review skill once the review prompt produces a useful, consistent issue list. The reusable part would describe how to review. The particular website brief and article would be inputs for that run.

I would keep confidential client material out of a broadly reusable personal workflow. It is easier to reuse a method across assignments when it does not carry another assignment's background with it.

Choose explicitly when you need a particular workflow

Where supported, choose a plugin or skill with @, or through + and More. Relevant installed skills may also be selected automatically; selection varies with the task. Source: migration and selection guidance.

I would test with a clean example, a vague brief, and a sample containing an unsupported claim. The last two tell you whether the process knows when to ask or flag a problem.

A connected service adds another decision

If a plugin connects to another app, review what access it asks for and which account you are using. A plugin does not remove that service's own access requirements. Availability also varies across devices; desktop-only plugins require desktop. Check OpenAI's plugin guidance.

For an article review, I would start with reading and feedback. If I later wanted a workflow to update a document or website, I would add that as a separate, deliberate step with a clear approval point.

Put it together: one article, three clear handovers

Here is an illustrative example you can adapt. Imagine you want to write a guide called “How to make content approvals less confusing.” We are planning the workflow, not reporting a tested client result.

The Project: Website content

Keep the audience note, approved bio, voice samples, services description, and current content plan here. Write a short note explaining which references are current and which ideas are still provisional.

Chat 1: Approval guide, research and brief

The first deliverable is a brief: who struggles with approvals, what they need to decide, the proposed process, examples we can honestly use, and any claims that need evidence. I would approve the scope before asking for the full draft.

The handover should say something like: “Brief v1 approved. Focus on a small team with one final approver. Leave out software comparisons. The sample approval tracker is illustrative.”

Chat 2: Approval guide, draft v1

Attach the approved brief. Ask for a draft that helps the reader identify the owner, the review deadline, the feedback location, and what counts as approval. Check whether the example makes those decisions understandable.

Now the handover might be: “Draft v1 ready for review. The example needs a clearer deadline. Check the proposed tracker fields. No customer outcomes are being claimed.”

Chat 3: Approval guide, QA and repairs

Provide the brief, draft, and relevant references. Use the review prompt or the tested review skill available to you. Work through the issues, then save the corrected version with its status.

The final handover could be: “Draft v2 checked against the brief. Internal links still need testing on the website. Shefa to approve the final page before publication.”

Notice what changed between stages. The next chat gets the decision and the relevant material. It does not have to reconstruct the whole history of how you arrived there.

You can adapt the same pattern to a proposal, a course outline, or a research summary. Name the deliverable, identify the shared material, and make the handover explicit.

Keep the useful bits findable

A Project can still get messy. The small habits matter after setup.

Name chats for the output

“Approval guide: QA” tells you more than “New chat.” I would use the topic, the stage, and a version only when it helps distinguish actual files. Choose words you would remember when searching later.

Keep one obvious current version

Use a short source note or tracker: current brief, current draft, status, owner, next action. If you keep an older version for reference, mark it as superseded. “Final final updated” is a surprisingly difficult status to work with.

Do not rely on a chat title alone to approve a deliverable. Put the approval beside the actual file or record it in the place your team uses for decisions. You can build a tracker for those stages with the example in my Sheets guide.

End with a restart note

Read that note before keeping it. Correct any decision it misunderstood. Then your next session can begin with the work itself, rather than a search through yesterday's conversation.

Keep client boundaries clear

I would use separate Projects for unrelated client assignments and check the source list before each task. That is an organisational choice; the Project name itself is not proof of privacy or access isolation. Review your actual workspace, sharing, and connected-service settings before adding sensitive material.

Personal writing samples should also be intentional. Use material you have permission to reuse. A client document is not automatically an appropriate example for your personal writing assistant.

A five-minute reset for the end of the week

I would keep the maintenance very small. Look at the work you expect to return to next week and ask:

• Can I find the current brief and draft?
• Do the chat names tell me what each one is for?
• Are old references clearly marked or removed from the active set?
• Have I recorded the decisions that were actually approved?
• Does each active item have a next action?

Where your interface offers pinning and archiving, use them to keep active work visible. Pinning changes where an item appears; it does not add context or permissions. Source: Projects and chats.

You do not need to reorganise your entire chat history before trying this. Pick the work you are doing now. Give that one Project a clear brief, start a focused chat, and leave yourself a useful restart note.

Then see what still feels difficult. That is the part to improve next.

A few questions you might still have

Sources, and something useful to read next

Product guidance checked November 1, 2026. These official pages support the feature descriptions; the suggested content workflow, prompts, and illustrative example are my editorial recommendations. Recheck availability before changing your setup.

• Projects and chats
• Moving custom GPT workflows to plugins
• Skills and plugins
• Using plugins and checking availability
• Using ChatGPT

If you want to put that structure around paid work, start with 16 practical ways to use ChatGPT to make money. Choose a service you can actually deliver, then use a Project to keep its brief, sample, and review process together.