A project groups work that belongs together: a client’s system overview, its onboarding flow and the files behind both. It gives future conversations a defined place to look for relevant context. Personal Projects are for organizing your own work; they are not a shared team workspace.
Use a boundary that matches the work
Name the project for a client, product or deliverable. Keep the source files and related conversations inside that boundary so a future revision can refer to a decision without rebuilding the brief. Moving a conversation should preserve its attachments, diagrams and earlier versions.
History provides a separate view of saved results, grouped by diagram with versions beneath the latest result. A project is the organizational context, while History is a way to find the work.
Choose a memory scope deliberately
Project-only context should remain within that project. A conversation for another client must not silently inherit the first client’s terminology, constraints or source content. Account memory is a different scope, appropriate only for information you permit to be reused more broadly.
A named brand palette can be selected explicitly without opening unrelated project memory. Review the project’s scope when moving a conversation or changing its sharing rules.
Review and remove context
Use Memory settings to inspect, correct or delete remembered information. A correction should supersede the old fact, and excluding a source should prevent it from being reused as context. Keep important task requirements explicit in the current conversation.
Deleting a project affects the work it contains. Review the deletion details and retained copies before confirming any destructive action.
Make it about your work
Edit this starting prompt, then send it when you are ready.