Keep a development brief in a ChatGPT project

A development project produces several kinds of work: understanding a failure, comparing approaches, reviewing a design, and explaining a change. Keep their shared facts in a small brief so each task can start with useful context.

ChatGPT project instructions and sources apply across that project's chats. A local project and a ChatGPT project provide different kinds of access; check whether the files are uploaded, connected, or read from an actual folder.

Build a brief that earns its place

Create a project for one codebase or sustained engineering effort. Add a brief you can maintain, plus the few source documents needed for its tasks:

Project: Search service
Goal: Keep keyboard navigation predictable while search results update.
Stack: JavaScript; confirm dependency versions from the attached lockfile.
Constraints: Keep the public query format and existing visual design.
Checks: Keyboard typing, deletion, result navigation, and the repository tests.
Source of truth: The attached files, identified by revision and upload date.
Open question: Should empty queries show recent searches?

Record the repository revision beside snapshots. A document describing an old implementation can remain useful, but it needs that date to be interpreted.

Put durable behavior in project instructions:

Use the maintained brief as context. Cite the source file behind a technical claim. Tell me when an answer depends on a file you cannot access. When a requirement conflicts with the current code, describe the conflict before proposing a change.

Keep the current bug and its temporary constraints in the task chat. This avoids turning last week's exception into a rule for every future task.

Use a new chat as a context check

Start a new chat inside the project and ask for its goal, constraints, source revision, and unresolved question. Require source names with the answer. Compare those references with the actual project sources.

Then change the brief's open question and repeat the check in another chat. You are testing whether the maintained document is available and understood, not whether the system can repeat something from the preceding conversation.

For a repository agent, maintain the execution rules in AGENTS.md as well. A ChatGPT project brief does not install that file in a checkout.

What goes wrong

Uploading several nearly identical briefs creates competing authority. A stale lockfile encourages version-specific advice for the wrong installation. Conversational memory can also carry preferences, but it is a poor substitute for a versioned engineering decision.

Keep one maintained brief, label historical material, and remove superseded attachments when they no longer help. Add a source because a task needs it.

How to check

Use a fresh project chat to request three facts with source references. Verify each against the named document. Include one question the documents cannot answer; the result should identify the gap.

For an implementation handoff, include the current revision and recheck it in the working repository. Project context helps a new task start; it does not prove the repository has stayed unchanged.