Verified against ChatGPT · 2026-07-30
Set up a Project so every chat in a workstream shares the same ground truth
Configures a ChatGPT Project's files and project-level instructions as durable shared context for an ongoing piece of work, with an explicit policy for what belongs at the project level versus what stays in one thread.
The prompt
Ready to copy — highlighted parts are example details you can swap.
You are helping set up a ChatGPT Project as the shared context container for an ongoing piece of work, so every new chat started inside it already has the right ground truth without re-explaining it, and so a fact that's true for one specific conversation doesn't leak into the project level and quietly apply everywhere. WORKSTREAM Rebuilding our customer onboarding flow over the next quarter — spans product, support docs, and email sequence work. FILES TO ATTACH Current onboarding flow screenshots (reference for all threads), a specific vendor contract PDF (only relevant to one thread), and our brand voice guide. FACTS THAT APPLY TO EVERY CHAT IN THIS PROJECT We're targeting self-serve SMB customers, not enterprise; the redesign has to ship before the Q4 renewal cycle; brand voice is direct, no exclamation points. FACTS THAT ARE THREAD-SPECIFIC, NOT PROJECT-WIDE The specific vendor's pricing tiers — only matters for the one thread about that contract. HOW LONG THIS PROJECT WILL LIVE Through end of Q4 this year, then likely archived. SETUP RULES Write the project-level custom instructions to hold only facts and rules that would be true for every conversation started inside this project, for as long as the project exists — a fact that's only true this week, or only relevant to one specific sub-task, belongs in that individual thread's opening message, not the project instructions, because project instructions apply silently to every new thread, and a stale one-off fact baked in there will keep resurfacing in unrelated conversations long after it stopped being true. Decide file placement by whether the file is reference material every thread in this project might need to check, versus a one-off input relevant to a single task — attach the former at the project level, and route the latter to the specific thread that needs it, since every file attached at the project level is available to every thread in the project, including ones that have nothing to do with what that file covers. If a fact seems like it might actually be project-wide but was only mentioned in the context of one specific task, flag that ambiguity and ask rather than deciding unilaterally — the cost of a wrongly-scoped fact differs in each direction: too narrow means re-explaining it every new thread, too broad means it silently colors answers in threads it has nothing to do with. Given the stated project lifespan, note anything in the project-level facts likely to go stale before the project ends, as a prompt to come back and update it rather than assuming project instructions set once stay accurate forever. OUTPUT FORMAT 1. The project-level custom instructions text, ready to paste into the Project's instructions field. 2. A file-by-file placement recommendation: project level or thread-specific, with the reason for each. 3. Any fact flagged as ambiguous in scope, with the question that needs answering to resolve it. 4. Anything likely to go stale before the project's stated end date, with a suggested check-in point.
Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
Project-level custom instructions and files apply automatically to every new chat created inside that Project without being restated, which is exactly the durability the feature is for, but that same mechanic is what makes an incorrectly-scoped fact expensive — a detail relevant to one sub-task, once placed at the project level, now silently colors every unrelated thread started inside the project going forward, including ones started months later by which point the original context is easy to forget existed at all. The file-placement distinction matters for the same structural reason: a file attached at the project level is retrievable by every thread's file-search, not just the thread that actually needs it, so a one-off contract PDF sitting at the project level is available to be quoted from in a thread discussing an entirely unrelated part of the work, creating a real risk of a detail from the wrong document surfacing in an answer where it doesn't belong. Explicitly flagging facts of ambiguous scope rather than deciding silently addresses an asymmetry in the cost of getting the placement wrong in each direction — under-scoping just means mild repetition, cheap to fix by restating it, while over-scoping means an assumption quietly shapes answers in contexts where it was never actually true, which is much harder to notice because nothing about a wrong answer signals that a project-level instruction caused it. Naming likely staleness against the project's stated lifespan turns an implicit assumption — that instructions written once stay accurate — into an explicit thing to revisit, which matters because nothing in ChatGPT's interface prompts a review or expiry of project instructions; they simply keep applying until someone manually notices they're wrong and edits them.
Verified against
ChatGPT GPT-5.1 (Projects) · 2026-07-30
Changelog
- 2026-07-30 — Initial publish, verified against ChatGPT GPT-5.1 Projects.
Building this for real?
This is a free starting point. If you'd rather have what Scult builds built and running for your business, that's Scult's day job.
EXPLORE WHAT SCULT BUILDS
