Give ChatGPT Work the right project context

Outcome

Put the project’s goal, sources, save location, and review rules where a new task can find them. Include the terms it needs to understand and the actions that require your approval.

Keep instructions, source material, working drafts, and checks clearly labeled. These tell a teammate or a new task how to work and what has actually been verified.

When to use it

Write project instructions when work has multiple sources, recurring terminology, or several review steps. They are especially useful when more than one person or task will contribute.

Keep it small for early experiments. Add structure only when it resolves a real routing, proof, ownership, or recovery problem. A folder tree is not useful merely because it looks organized.

Operating pattern

Use four instruction layers, each with one job:

1. ChatGPT Work instructions: universal voice, collaboration preferences, and broad working defaults that should follow you across conversations.
2. Global working instructions: shared execution rules for tool routing, authorization, validation, and handoff behavior. Use the supported global instruction surface in your current environment.
3. Project-folder `AGENTS.md`: the mission, source hierarchy, workflow, guardrails, and definition of done for one project, starting at the repository root and becoming more specific in nested folders when needed.
4. Skills and runbooks: detailed procedures for repeatable jobs. Keep them out of the broad instruction layers until the procedure is actually needed.

Do not call every layer AGENTS.md. Personal preferences belong in the product’s supported instruction or personalization surface. File-backed projects may support global and project AGENTS.md files. Verify the supported locations, discovery order, and precedence before relying on them. Use AGENTS.override.md only where supported and for a deliberate temporary or specialized override.

These layers have different jobs. Put durable communication preferences in the general instruction surface, shared execution rules in the supported global instructions, and workstream-specific sources, owners, checks, and approval rules beside that workstream. Never assume one working environment automatically inherits instructions, files, or connected accounts from another.

List approved connectors separately from actual source evidence. A connection means a tool may be available; it does not prove that a particular document is readable, current, or authorized for this task. A current application view, user-provided screenshot, or optional computer-history snippet may help locate the right context only when explicitly permitted. Limit history to the named application, question, and time window, then verify any material claim against its original source.

Separate four kinds of project state:

1. Instructions: how work should be performed.
2. Sources: authoritative inputs and their owners.
3. Working output: drafts, analyses, and intermediate artifacts.
4. Proof: tests, receipts, approvals, or verified target-state evidence.

Place durable project instructions in the supported project surface, or a project-folder AGENTS.md where supported. Create a source map that records source owner, purpose, grain or scope, currentness expectation, and unsupported uses. Check OpenAI's current `AGENTS.md` guide before relying on discovery or precedence behavior.

Use explicit lifecycle language: draft, validated, release candidate, and published. Currentness is separate. A validated artifact can still be stale; a current preview can still be unpublished.

Create run or checkpoint records for material work. They should link the input revision, generated result, validation performed, known gaps, and next owner.

Copyable implementation

# AGENTS.md

## Purpose
[What this project produces and for whom]

## Source hierarchy
1. [Authoritative system or artifact]
2. [Approved supporting source]
3. [Context-only material]

## Working rules
- Read the relevant source before making mutable factual claims.
- Separate facts, assumptions, recommendations, and evidence gaps.
- Keep source data, generated output, preview, and published state distinct.
- Preserve existing unrelated work.

## Approved context
- Use only [named connectors, folders, and source records].
- Inspect application views or history only with explicit, bounded consent.
- Treat screenshots and summaries as routing context unless the user establishes them as authoritative for the specific observation; do not infer unsupported source, backend, or current state from them.

## Validation
[Named checks and required evidence]

## Approval boundaries
Draft locally by default. Obtain explicit approval before outbound messages,
publication, deployment, access changes, purchases, or destructive actions.

Pair it with a source map:

| Source | Owner | Purpose | Currentness | Supported use | Unsupported use |
|---|---|---|---|---|---|
| [artifact] | [role] | [why it exists] | [rule] | [scope] | [limits] |

Example

For example, a research team creates a “Market Landscape” project. Its AGENTS.md says the approved survey export is authoritative for respondent counts, interview notes are qualitative context, and generated summaries are never source data.

The source map records that the survey is refreshed monthly and supports aggregate analysis but not individual performance assessment. A task produces a draft dashboard from the latest export. Tests validate row counts and category mappings, but the dashboard remains a local preview. The run record says validated, names the export version, and notes that publication approval is still missing.

The record makes the missing publication approval visible.

Approval boundary

Instructions can constrain behavior; they do not create access or confer authority. Writing an AGENTS.md, source map, or deployment runbook does not install a tool, connect an account, grant credentials, approve a source, or activate an automation.

Treat external messaging, publication, deployment, permission changes, source replacement, destructive cleanup, and financial decisions as explicit approval gates. If lower-level instructions conflict with a higher-level safety boundary, stop and surface the conflict.

Never store credentials, private tokens, personal data, or sensitive source content inside portable public templates.

Validation

Ask a fresh reviewer to answer:

• What is this project for?
• Which source wins when two values conflict?
• Which instruction applies globally, and which belongs only to this project?
• How current must each source be?
• Where do drafts and proof records live?
• What checks establish validated?
• What additional evidence establishes published?
• Which actions require a person’s approval?
• Which connectors or app-context surfaces are actually available and approved?

Then inspect one recent output. Confirm its lifecycle label, currentness, source revision, validation evidence, gaps, and owner are all explicit.

Failure modes

An oversized instruction file becomes unreadable policy theater. Repeated rules drift across folders. A source map without owners or currentness cannot resolve disputes. A folder named “final” is not proof of approval or publication.

Other failures include embedding volatile facts in durable instructions, citing generated summaries as authoritative sources, and copying confidential paths or examples into public templates. Avoid using every available source simply because it is accessible; prefer the smallest authoritative set.

Finally, do not let the architecture hide uncertainty. When lineage, currentness, or permission is missing, represent the output as blocked or provisional rather than filling the gap with inference.