The Weekly Update Project

Rule 1: Not a filing cabinet

Most people who try Projects use them as a folder, a place to park old chats so they are easier to find. That is the least useful thing a Project does. A filing cabinet stores what already happened.

What you want is closer to a new hire who has already been onboarded: someone who knows what you are working on, who reads your work and how you like things worded, before you ask for anything. So before you build, pick one piece of recurring work this Project will own. For this guide, it is the weekly update.

Rule 2: An onboarding packet, not a clever prompt

Nobody does good work from a two-line job description. A new team member gets the current priorities, who they will be working with, and an example of the work done right. ChatGPT needs the same packet, uploaded instead of handed over.

The packet is three files and one line. The templates are below. Here is the build in ChatGPT, as it looks today:

• Create the Project. In the left sidebar, select the + next to Projects. Name it after the work, for example "Weekly Update", and select Create project.
• Upload the three files. Open the Sources tab and select Add sources. Add all three files.
• Add the one line. Select the ⋯ menu at the top right, then Project settings. Paste your line into Instructions and select Save.
• Ask for the first draft. Start a chat inside the Project and give it this week's news in a sentence or two.

One setting to know: the memory dropdown in the Create project box is set once, at creation, and cannot be changed later. "Default" means the Project can draw on your wider ChatGPT memory, and the other way round. If you want this Project to work only from its own files, look at that dropdown before you select Create project, not after.

Rule 3: Same hire, second job

You would not re-onboard the same person every time you gave them a new task. Once your Project is set up, use it for every version of that task: the long update for your own team, the short one for the board, a version for a different audience. A new chat, not a new Project.

One thing I found building this for the video. A new chat in the same Project already knows the files: the priorities, the audience, the voice, the example. It does not reliably know the news you gave it in a different chat. My first board-version request, with no facts in it, came back using last month's numbers from the example file. So every time, give it this week's facts in the prompt. That is one sentence. Everything else, you never re-explain.

It came back in the Wins / Risks / Asks format, cited the audience file, and pulled the quarter's baseline and the approved budget straight out of the packet without being told.

Rule 4: One Project per recurring deliverable

The mistake on the other side is cramming everything into one giant Project because the first one worked. That is like asking one person to be your finance lead, your recruiter and your marketing writer at once. Each needs its own context and its own voice, and mixing them muddies all three.

Before you start a new Project, ask one question:

The weekly update is one Project. A content calendar is a different one.

Rule 5: Keep the example fresh

The worry with any saved setup is that it goes stale. This one does the opposite if you do one small thing. The file that matters most is the example done well. The priorities and audience notes barely change month to month. The example is the file you keep touching.

Once a month, drop your best recent update into the example file. In the Sources tab, add the new one and take the old one out. That is the entire maintenance job: thirty seconds, once a month, and it keeps getting closer to right instead of drifting away from it.