Give ChatGPT a working brief it can keep using.

What belongs in project instructions?

Put the rules you want to reuse here. A sales project might always separate signed revenue from pipeline. A marketing project might use an approved claims document and write for independent business owners. A client-reporting project might always lead with the decision the client needs to make. Those choices save you from repeating the same working brief in every chat.

Keep temporary requests outside the instructions. 'Analyze the August export' belongs in a chat; 'use the supplied reporting period and flag missing dates' can stay in the project. Avoid filling the instructions with old targets, expired offers, or competing commands. Give each rule a purpose you could explain to a colleague. The goal is a maintainable brief, not a collection of tricks.

• Stable: audience, definitions, approved tone, review rules, usual output structure.
• Changing: current figures, campaign dates, customer notes, and today's specific question.
• Sensitive: add only material your organization permits you to use in the selected account.

Set up one project around one recurring job

A useful first project has a specific output: 'weekly pipeline review' is easier to evaluate than 'help with sales.' OpenAI's current web documentation describes separate Chats and Sources sections, with project context available across its chats. A ChatGPT project does not automatically expose a folder on your computer. Upload or connect the material you want it to use. Official Projects documentation

1. Create or open the relevant ChatGPT project. Choose a name that describes the work.
2. Use this builder to define the recurring outcome, audience, source rules, and output format.
3. Add the generated brief to the project's instructions field. Interface labels can vary.
4. Add the permitted reference material to the project's sources. Prefer a small set of clearly named, current documents.
5. Start a new chat inside the project and run the test requests below. Review the result before using the setup for live work.

A complete example: a weekly sales review

Here is a fictional setup for Northstar Studio, a small services business. The manager wants a weekly review that distinguishes what actually happened from what the team hopes will happen. The brief below is an original starting point; it is not a claim that we ran a sales workflow or measured a performance improvement.

Purpose: Help our sales manager prepare a weekly pipeline review for the owner. Use the attached export and metric definitions. Keep closed-won revenue separate from open pipeline. Preserve the supplied currency, dates, and reporting period. If a required field is missing, identify it before calculating the affected metric.

Deliver: A short decision summary, a table of pipeline changes, the three most important risks, and next actions with proposed owners. Label recommendations as recommendations. Cite the file and relevant row, sheet, or section for material figures when available. Do not invent customer commitments, close dates, or reasons a deal stalled. Draft follow-ups for review; do not send messages or update records.

Adapt the brief to the work you actually do

For a marketing project, replace the pipeline definitions with an approved offer, audience description, brand examples, and a list of claims you can substantiate. Ask for a campaign brief with the hypothesis, message, evidence, channel, and next experiment. A polished headline is not enough if it promises a result your product cannot support.

For operations, define the process owner, inputs, exception rules, and desired handoff. Ask for a procedure that names prerequisites and explains what to do when an input is missing. For client reporting, define the reporting period, metric calculations, and decision required. Keep client-specific material in the appropriate project and follow your organization's access rules.

Use an example of a good finished deliverable whenever you can share it safely. Explain which parts to imitate—perhaps its structure and level of detail—and which parts must not carry over, such as the previous client's figures.

Test the setup with three small requests

Instructions express the behavior you want; they do not guarantee compliance or accuracy. Test the brief with harmless sample data before attaching a live customer export. These are proposed acceptance checks you can run, not reported test results.

1. Normal input: Supply five fictional deals and ask for the weekly review. Check that all five are accounted for, open pipeline is separate from closed-won revenue, and the output follows your requested structure.
2. Missing input: Remove the currency and reporting period. Ask for a final revenue summary. A useful response should expose those gaps instead of silently choosing a currency or inventing dates.
3. Conflicting input: Supply two short source notes with different approved launch dates. Ask for the launch plan. The response should flag the disagreement and ask which source controls before treating either date as settled.

Improve the rule that failed

When a result fails a check, identify the exact mistake. 'Be more accurate' is hard to evaluate. 'Do not include open opportunities in closed-won revenue; show the status filter used' gives you something concrete to check next time. Change one meaningful instruction, rerun the same sample, and keep a short revision note.

Review the brief when your work changes. Remove obsolete sources, update definitions, and retire rules that conflict with current priorities. OpenAI's prompting guidance recommends stating the outcome, context, format, and consequential boundaries, then inspecting and refining the result. Official prompting guidance