# ChatGPT Work: a practical team starter kit
> Design the Work: a practical framework for getting real work done.
This guide is for people who want to get more out of ChatGPT Work.
Access and available tools vary by account, workspace, device,
and explicit permission. Start with a job you actually do. Share the approved
background, examples, and sources you would give a teammate. Work through a
real example and correct what matters. Draft a Skill only when the method
genuinely repeats, then test it on a new example before trusting it.
The goal is more leverage without giving up control. ChatGPT can help you
understand the work, prepare a draft, and repeat a method you have already
tested. You still decide what gets sent, published, approved, or changed.
The guide is public-safe and portable. Product capabilities change, so check
what is available and permitted in your own environment before relying on a
feature or connection.
## Find the part you need
- **Your first 15 minutes:** choose one real workstream, identify its owner,
work from a trusted source, and inspect the actual result.
- **Manager onboarding:** run a five-day pilot with one real workflow per
person, safe examples, clear approvals, and a Friday retrospective.
- **Copyable prompts:** start with the smallest request for project
instructions, Skills, consent-bounded app context, heartbeats, or a Chief of Staff.
- **Agent-readable starting points:** read /START-HERE.md and /llms.txt, then
load only the guidance needed for the current job.
- **How it works:** understand the six stages and know what should come next.
- **Playbook:** find a specific example, explanation, and practical
next step without reading every chapter.
- **30-day plan (chapter 13):** work through one real project at a reasonable
pace; draft while the context is fresh and validate with fresh examples.
- **Sites:** build a slide presentation, dashboard, or review from an example
prompt at /sites. Chapter 14 explains sources, collaboration, and review.
- **Supporting prompts and checklists:** use only the starting point that
helps with the work in front of you.
- **Longer-running work:** use clear checkpoints, explicitly approved plans,
bounded resources, verified receipts, and recovery inside the existing project.
If you are new, start with one real workflow and chapter 1. Use the 30-day plan
when you want help deciding what to try next. If you already have a workflow,
skip to the first part you have not actually tested. The aim is not to install
everything; it is to make one piece of real work better.
## Playbook contents
1. [Get real work done with ChatGPT](#1-codex-as-work-hub) — beginner | Tips 1–3
2. [Keep recurring work in one place](#2-durable-projects-and-task-architecture) — intermediate | Tips 4–13
3. [Give ChatGPT Work the right project context](#3-agents-folders-and-proof) — intermediate | Tips 14–23
4. [Know when a workflow becomes a Skill](#4-artifact-to-automation) — intermediate | Tips 24–33
5. [Let ChatGPT help you keep track of work](#5-personal-chief-of-staff) — intermediate | Tips 34–43
6. [Chief of Staff](#6-cos-loop) — advanced | Tips 44–51
7. [Let ChatGPT Work help without giving up control](#7-bounded-proactivity) — advanced | Tips 52–63
8. [Move work between the tools you already use](#8-cross-application-work) — intermediate | Tips 64–75
9. [Know what is current, checked, and approved](#9-currentness-lifecycle-approvals) — advanced | Tips 76–84
10. [Help a team work together without losing ownership](#10-team-operating-systems) — advanced | Tips 85–90
11. [Pick the work back up where you left off](#11-continuity-and-recovery) — intermediate | Tips 91–97
12. [Keep longer work safe and recoverable](#12-work-never-stops) — advanced | Tips 98–101
13. [Build one reliable workflow in 30 days](#13-thirty-day-installation) — beginner | Installation plan
14. [Build a Site that becomes part of the work](#14-sites-as-working-artifacts) — advanced | Installation plan
## Template contents
- [Tell ChatGPT how you like to work](#template-chatgpt-work-instructions) — beginner
- [Give ChatGPT Work the same ground rules across projects](#template-global-agents) — advanced
- [Tell ChatGPT Work how this project works](#template-project-agents) — intermediate
- [Keep the project and its sources in one place](#template-project-charter-source-map) — beginner
- [Track active work and who owns it](#template-task-registry) — intermediate
- [Pick the work back up without starting over](#template-checkpoint-restart-card) — beginner
- [Hand work to the next person or task](#template-task-handoff) — intermediate
- [Write down a workflow you can repeat](#template-workflow-specification) — intermediate
- [Turn repeated corrections into a Skill](#template-skill-specification) — advanced
- [Automate one proven step safely](#template-automation-contract) — advanced
- [Keep the important decisions with a human](#template-approval-matrix) — advanced
- [Improve what you keep having to correct](#template-reflect-and-refine) — intermediate
- [Ask ChatGPT Work to review how you work](#template-self-audit-installation) — beginner
- [Run a practical five-day team pilot](#template-manager-pilot) — beginner
- [Record what a heartbeat actually did](#template-heartbeat-receipt) — intermediate
---
# 1. Get real work done with ChatGPT
_beginner | Start with real work, give ChatGPT the right context, and keep the decisions that matter under your control._
## Outcome
ChatGPT Work starts with a simple question: what real work would you like help getting done? Choose something you already understand, share the useful background, and work through the result together.
For example, if you write the same monthly update, show ChatGPT the latest source, last month's example, who will read it, and what you want to check. Work through the first update together and correct what matters. If the job is worth repeating, ask ChatGPT Work to draft a Skill while that example and your corrections are still in context. Test the draft on a fresh update before you trust it.
Keep the sources, draft, and corrections together so you can return to the work and reuse the parts that hold up. Keep important decisions with you.
### The plain-English model
You do not need to learn a new operating vocabulary before beginning. In this guide:
- A **task** is the active conversation advancing one outcome.
- A **project** is the durable home for related instructions, sources, and workstreams.
- An **artifact** is the thing the work produces: a brief, analysis, deck, app, plan, or other reviewable output.
- A **workflow** is the repeatable sequence that produces that artifact.
- A **Skill** captures useful instructions from real work. Draft it while the example and corrections are fresh; test it on new examples before calling it reliable.
- An **automation** adds a trigger or schedule to a bounded, already-proven part of the workflow.
- A **checkpoint** records enough verified state for a fresh task or person to continue.
- An **approval boundary** names the action that still needs an accountable human.
Start with the actual task. Add projects, workflows, Skills, and automation only when real work shows why you need them.
### Understand the layers before adding complexity
The model supplies general reasoning. Available foundational guidance helps with common artifacts such as spreadsheets, presentations, and documents. Approved tools and connectors provide only the access you have actually configured. Your global and project instructions explain how you work, while personal or shared Skills capture a repeatable method for one job.
Some workspaces can distribute approved shared Skills through plugins. Verify that capability and the actual package before relying on it; installing a plugin does not grant access, approve an action, or replace the workstream owner.
A Skill guides the current workflow; it does not retrain the model, grant new access, or approve an action. Availability varies by product, account, and workspace, so verify which capabilities you can actually use instead of assuming a screenshot or someone else's setup applies to yours.
A screenshot, current application view, or explicitly approved computer-history snippet can clarify context when that capability is available. Treat it as a clue, not the source of truth. Ask before inspecting history, define the time window and application, and avoid unrelated activity or sensitive material.
## When to use it
Use this pattern when work will require more than one step, source, or review cycle. It is especially useful for research, planning, recurring reporting, multi-document synthesis, operational projects, and deliverables that must survive interruption.
Use a lightweight one-off prompt instead when the request is genuinely disposable: a short rewrite, a calculation whose inputs are already present, or a question that creates no future state.
Give the work a dedicated project when the same context, corrections, sources, or review steps keep coming up and someone needs to own what happens next.
## Operating pattern
Begin each meaningful task with a clear description of the job:
1. Name the outcome and intended audience.
2. Identify the trusted sources and check whether they are current.
3. Say what is out of scope and what still needs your approval.
4. Explain what a good, checkable result looks like.
5. Ask for one useful next step.
During the task, keep facts, assumptions, recommendations, and unresolved questions separate. Have ChatGPT Work reread the relevant artifact before citing it, and distinguish a draft from a validated output. When the work changes lanes, create a checkpoint that records decisions, evidence, open risks, and the next action.
End each session with one of four explicit states: completed, ready for human review, waiting on a named dependency, or paused with a restart card.
## Copyable implementation
```markdown
# Real-work brief
Objective: [specific outcome]
Audience: [who will use or approve it]
Authoritative sources: [artifacts, systems, or people]
Approved tools and visible app context: [only what I explicitly authorize]
Currentness requirement: [date, version, or refresh condition]
Constraints: [security, style, timing, scope]
Non-goals: [what this task will not do]
Approval boundary: [actions requiring my explicit approval]
Acceptance checks: [observable proof of completion]
Start by inspecting the sources. Separate facts, assumptions,
recommendations, and evidence gaps. Advance one bounded step, validate it,
and leave a checkpoint if the work is not complete.
```
Reuse this brief at the top of a durable task or in its project instructions. Update it when the job changes rather than carrying old assumptions into new work.
## Example
For example, a strategy lead is preparing a quarterly planning brief. They create a durable task, identify the approved planning document and latest operating review as authoritative sources, and set a non-goal of changing any source data.
ChatGPT Work first produces a source inventory and identifies two conflicting dates. The lead resolves the conflict, then asks for a structured synthesis. After drafting, ChatGPT Work checks every claim against the named sources and creates a review checklist. The lead edits the recommendation and approves the final wording. The task ends with a checkpoint linking the reviewed brief and listing two follow-ups for the next planning cycle.
The value came from keeping the real sources, decisions, corrections, and review steps clear, not just from generating text faster.
## Approval boundary
Working in ChatGPT Work does not grant permission to act elsewhere. Reading, analysis, local drafting, external editing, messaging, publishing, deployment, access changes, spending, and destructive actions are distinct authorization states.
Default to preparing a reviewable result. Require explicit human approval before sending messages, publishing content, changing access, deploying software, making purchases, or deleting or overwriting material. Installation, connector configuration, account authorization, and runtime activation are also separate actions; a written workflow does not perform them.
## Validation
At any checkpoint, verify that:
- The objective and audience are still accurate.
- Each material claim traces to a named, current source.
- Assumptions are labeled rather than presented as facts.
- The output has an observable acceptance check.
- Any connector, screenshot, or history context stayed within its approved scope.
- External or irreversible actions remain unperformed without approval.
- Another person or a fresh task could resume from the checkpoint.
A useful final question is: “What evidence proves the stated result, and what remains only drafted or inferred?”
## Failure modes
The most common failure is treating conversation history as a source of truth. Context helps with routing, but mutable facts still need current evidence.
Other failures include one enormous task with no checkpoints, vague instructions such as “handle everything,” hidden changes to scope, and confusing polished language with validated work. A task can also become a dumping ground for unrelated projects, making source ownership and completion impossible to judge.
Avoid performative busyness. If no bounded safe step is available, the correct result may be a concise blocker, a request for a decision, or a no-change report. A work hub should make state clearer, not manufacture activity.
---
# 2. Keep recurring work in one place
_intermediate | Give repeated work a clear home so you can find the right context, see what is happening, and pick up where you left off._
## Outcome
Keep a recurring job’s sources, instructions, and results in one project. Use an existing task to continue the same outcome, and a new task for a separate outcome. Record the owner, status, and next decision so you can find the work again.
A task registry gives you a defined list to review for missing owners, duplicate work, or results waiting for review. If you ask ChatGPT Work to review it, limit the review to that list. Save important context and remaining obligations in project files before archiving a conversation.
## When to use it
Create a durable project when a domain has recurring sources, specialized instructions, repeated deliverables, or a lifespan longer than one session. Examples include quarterly planning, customer research, a hiring process, or a product launch.
Organize by the workstream, not the application. A monthly forecast project can keep its approved data sources, spreadsheet, presentation, review notes, and reusable checks together. Separate projects named only "spreadsheets," "slides," or "queries" split the decisions and corrections that belong to the same job.
Keep one primary task for each outcome. Independent outcomes may have separate tasks; link them from the same project so ownership is clear. Create a new task when the objective, acceptance contract, security boundary, or owner changes materially. Continue the current task when the next action uses the same sources and definition of done.
Archive completed and superseded tasks after recording a reusable result and any remaining obligations.
## Operating pattern
Use a four-level model:
1. **Portfolio:** the small set of durable domains competing for attention.
2. **Project:** stable instructions, sources, vocabulary, and governance.
3. **Workstream:** a recurring outcome with a clear owner.
4. **Task:** the active unit that advances one outcome.
Name tasks for retrieval rather than chronology: `; — `. Maintain a registry with the canonical task, owner, state, source links, last verified checkpoint, next action, and review date.
Before creating another task, check whether the same source, outcome, and human owner already point to an active workstream. Reuse that owner when verified. If the match is uncertain, record the uncertainty and ask; a second task is not a safe substitute for missing ownership evidence.
Use the same states in the guide and registry: `active`, `waiting`, `review`, `blocked`, `paused`, `complete`, and `archived`. Use `waiting` for a named dependency, `blocked` for an issue requiring intervention, and `paused` for work deliberately stopped. A draft awaiting review stays in `review`. A scan may recommend a state change, but evidence should support it. “No recent message” does not necessarily mean “stalled.”
Checkpoint after three major milestones, before changing lanes, or whenever a different person should be able to continue safely.
## Copyable implementation
```markdown
# Task registry
| Project | Canonical task | Owner | State | Last checkpoint | Next action | Review date |
|---|---|---|---|---|---|---|
| [domain] | [Project; Subject — purpose] | [name/role] | active | [link/date] | [bounded verb] | [date] |
## Task rules
- Keep one primary task per outcome; link related tasks with independent outcomes.
- Keep the workstream's sources, files, Skills, and review history together.
- Propose a new task when objective, owner, security boundary, or acceptance contract changes; create it only if the user explicitly requests it.
- Check the existing owner before creating a potentially duplicate task.
- Record decisions and evidence before archiving.
- Flag duplicates; do not merge or close them automatically.
- A scan may advance at most one specifically authorized, reversible internal step.
- If no safe step exists, report the blocker or no change.
```
Add a short project index that points to each registry and defines which tasks are canonical.
## Example
For example, an operations manager maintains a project called “Vendor Renewal.” The project contains stable policies, the approved contract repository, and a calendar of renewal dates. Its canonical task is named `Vendor Renewal; Analytics platform — decision package`.
The registry shows the task as `waiting` because a security review is missing. A routine scan confirms the review is still absent and finds no newly approved evidence. Instead of drafting a recommendation from outdated notes, ChatGPT Work updates nothing and reports: dependency unchanged; owner and review date remain valid.
Later, the review arrives. ChatGPT Work verifies the document, changes the task recommendation to `review`, and prepares a decision summary. It does not accept the renewal or contact the vendor.
## Approval boundary
A registry authorizes inspection and internal organization only to the extent explicitly configured. It does not authorize closing tasks owned by other people, reassigning work, merging records, changing due dates, sending reminders, or committing the organization to a decision.
Allow automatic changes only when they are reversible, internally scoped, and rule-based. For example, adding a verified checkpoint link to a local registry. Require approval for outbound communication, priority changes, access changes, destruction, publication, financial commitments, or actions affecting another person’s workflow.
Installation, project creation, connector setup, and scheduled scans require separate configuration and authorization.
## Validation
Audit the architecture monthly:
- Every project represents one durable domain.
- Every active outcome has one primary task; related tasks have distinct outcomes and a clear owner.
- Related applications and outputs stay with their workstream rather than becoming separate ownership silos.
- Each task has an owner, state, and bounded next action.
- Checkpoints identify evidence rather than relying on transcript memory.
- Waiting tasks name the dependency and expected owner.
- Complete tasks have a reviewable result and no hidden follow-up.
- Archived tasks can be found through the project index.
Sample a fresh task and test whether it can resume using only the project instructions, registry, and latest checkpoint.
## Failure modes
Too many projects fragment context; too few mix unrelated sources and permissions. Date-only task names become impossible to retrieve. Long-lived “miscellaneous” tasks hide ownership and make completion meaningless.
Automatic scans can also create noise by repeatedly declaring unchanged work urgent, generating follow-ups no one requested, or using inactivity as proof of failure. A task registry is not a surveillance system or a substitute for prioritization.
Do not duplicate the same plan across a task transcript, spreadsheet, and document without naming one canonical surface. If two records disagree, stop and reconcile the source hierarchy before advancing the work.
---
# 3. Give ChatGPT Work the right project context
_intermediate | Show ChatGPT Work how you work, which sources to trust, where to save the result, and when to stop and ask._
## 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](https://developers.openai.com/codex/guides/agents-md) 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
```markdown
# 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:
```markdown
| 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.
---
# 4. Know when a workflow becomes a Skill
_intermediate | Do the real work, draft the Skill while the context is fresh, test it on new examples, and automate carefully._
## Outcome
Start with a real piece of work. Give ChatGPT the context, trusted sources, and example you would give a teammate. Work through the task and correct what matters. Draft the Skill while the example and your corrections are still fresh. Test that draft on new examples before calling it reliable.
Automation comes later. Before anything runs on its own, you should know which sources it can use, what a good result looks like, when it needs to stop, and what still needs your approval. The goal is more help with the work, not less control over it.
Keep the layers distinct: the model provides general capability, foundational guidance supports common artifact types, approved tools provide available access, and a personal or approved shared Skill adds the method for a real workstream. Teams may distribute shared Skills through plugins only when that capability is available and approved. Writing or running a Skill does not retrain the model.
## When to use it
Begin with the actual task when the problem is new or the result is still unclear. Work through a real example before asking ChatGPT to describe the whole process.
Draft a Skill when you have just seen which sources, instructions, corrections, and checks should carry into the next example. Do it while that work is still available in context. Review [OpenAI's current Skills documentation](https://developers.openai.com/codex/skills) before packaging one.
Treat the first version as a draft. Test it on fresh examples before relying on it or adding automation. Automate only when the starting conditions are clear, permissions are narrow, failures can be detected, and the next step can be reviewed.
Keep high-ambiguity, high-consequence decisions human-led even if parts of their preparation are repeatable.
## Operating pattern
Use the right order:
1. **Choose recurring work:** pick an actual job worth doing again.
2. **Share the context:** provide the source, audience, example, and approval boundaries.
3. **Work through a real example:** do the actual task with ChatGPT.
4. **Correct what matters:** explain the source checks, judgment, and quality you want.
5. **Draft the Skill here:** capture the method while the real work and corrections are still in context.
6. **Test on fresh examples:** find out whether the draft works with new information.
7. **Improve and reuse:** keep what carries over and fix what does not.
Use an actual example and your corrections to make the instructions specific. Capture them before the useful context is lost.
**Test on fresh examples.** One successful result is not enough to establish that the method is reliable. Check the draft on new work before adding automation.
At every stage, identify the trusted source and the person who approves the result. Preparing an action is not the same as being allowed to take it.
Version material changes. Test both the happy path and missing, stale, contradictory, unauthorized, and no-change cases. Treat a clean no-change result as success when nothing requires action.
Maintain the Skill instead of treating its first version as permanent. Review recent corrections and failures weekly; perform a deeper monthly cleanup using fresh representative examples. Retest when the workflow, source, owner, approval rule, model, or foundational guidance changes, and remove instructions that no longer add value.
## Copyable implementation
```markdown
# Workflow and Skill draft
Outcome: [user-visible result]
Current state: real example | Skill draft | tested Skill
Trusted sources: [original files and current information]
Real example: [the actual work you completed]
Corrections to keep: [source checks, decisions, and quality]
Details to leave out: [one-time facts, dates, and files]
Next fresh-example test: [what the draft needs to prove]
Human approval: [what still requires your decision]
Maintenance: [weekly correction review; monthly fresh-example retest]
```
If automation becomes useful later, also record:
```markdown
What starts it:
What it is allowed to read or prepare:
How to prevent duplicate work:
Where to pick the work back up:
What should happen if a source is missing:
When a person must approve the next step:
```
## Example
For example, a program manager needs a weekly risk summary. They show ChatGPT the three approved sources, last week's report, and the decisions the summary supports.
They work through the real report and correct the source dates, risk descriptions, and recommendations. While those examples and corrections are still in the conversation, they ask ChatGPT Work to draft a Skill. The draft records the source order, quality checks, and the need for a person to judge severity.
Next week, they test the draft on a new report. If it misses a changed risk or makes a decision it should not make, they improve the Skill and test again. Only after the method works on fresh examples should they consider scheduling a source scan. Sending the report and changing risk status remain human decisions.
## Approval boundary
A documented Skill is not installed, a packaged integration is not connected, and a scheduled configuration is not necessarily active. Installation, configuration, authentication, authorization, scheduling, and activation are separate states that require their own evidence.
Do not automate sending, publishing, deployment, permission changes, financial commitments, destructive operations, or people-management decisions without explicit scoped authorization. Automation may prepare an action and assemble evidence for approval.
Use the least privilege needed. Never place secrets or live credentials in templates, examples, logs, or generated artifacts.
## Validation
Before treating a Skill draft as reliable, confirm:
- The real work, desired result, and owner are clear.
- The draft was written while the example and corrections were still available.
- Fresh examples produce good results without relying on the first example's facts.
- A different example exposes missing exceptions without copying the original answer.
- Inputs have owners and currentness rules.
- Variations and unsupported cases are documented.
- Validation detects materially wrong output.
- Duplicate runs are safe or prevented.
- Failures produce an actionable state rather than silent success.
- Approval boundaries are enforced in behavior, not merely described.
- A person can stop, inspect, and recover the process.
- The review cadence and owner are recorded, with stale guidance removed.
For automation, run it in an isolated or review-only mode before enabling consequential actions.
## Failure modes
Drafting a Skill without examples or verified workflow details leaves assumptions untested. Waiting until the useful conversation is gone loses the example, feedback, and reasoning that should have taught it. Calling the first draft reliable skips the fresh-example test.
Other failures include automating an untested workflow, trusting stale sources, duplicating work, and letting an agent send or change something without approval. Do not add automation because a task is boring. Add it only when the work has been tested and a person can still stop or review it.
The safest system stops when evidence, permission, or currentness is missing. Manual review is not technical debt when it contains the judgment the process cannot reliably encode.
---
# 5. Let ChatGPT help you keep track of work
_intermediate | Turn meetings, commitments, and open questions into a clear list of next steps you can review._
## Outcome
See your commitments, upcoming reviews, unanswered requests, and project risks in one place. A Chief of Staff workflow can help you prepare a brief from sources you approve and see which decisions need your attention. When specifically authorized, it may prepare one bounded internal next step.
The system is useful because it reduces context switching and makes obligations explicit. It does not impersonate you, set priorities without guidance, or treat every unread item as important. You retain authority over commitments, communication, and tradeoffs.
This is a practical operating pattern, not a claim that every account includes a ready-made Chief of Staff product. Chapter 6 explains four distinct roles: Detect, Incubate, Collaborate, and Reflect.
## When to use it
Use a personal Chief of Staff loop when work spans multiple projects, meetings generate follow-ups, messages contain obligations, or important tasks are being crowded out by reactive work.
Start with a narrow daily or weekly brief. Add meeting preparation, follow-up review, and checks for unanswered requests only after you trust the sources and classifications. Avoid broad monitoring if the input systems contain highly sensitive material or if organizational policy does not permit access.
For a single quiet project, a simple task registry may be enough.
## Operating pattern
Define the loop around five questions:
1. What changed in the approved sources?
2. What requires my decision, response, or review?
3. What commitments have I made, and by when?
4. Which upcoming moments need preparation?
5. What one bounded internal action can reduce risk now?
Create one source map and one bounded cadence for the Chief of Staff workflow. Keep each workstream's files and execution in its existing project. For each item, preserve the source link, owner, date, confidence, and reason it matters. Distinguish commitments from suggestions and explicit deadlines from inferred urgency.
Produce a ranked brief with three lanes: act, review, and watch. Allow one reversible internal preparation step only when the action is explicitly in scope, for example drafting an agenda or assembling approved source material. End with separate counts or descriptions for work detected, work actually advanced, decisions needed, blockers, and no-change findings.
One weekly home-base task and one weekday controller are a useful configuration when scheduling is supported and the user approves it. They are not automatic product entitlements. Keep requests open until the actual owner or source confirms completion.
Regularly reflect on false positives, missed items, and abandoned categories.
## Copyable implementation
```markdown
# Personal Chief of Staff scan
Approved sources: [calendar, project registry, selected messages, notes]
Existing workstream owners: [the approved project or task registry]
Time window: [current and look-ahead periods]
Priority rules: [commitments, decisions, deadlines, strategic importance]
Excluded content: [private or irrelevant categories]
Return:
1. ACT — explicit commitments or time-bound decisions
2. REVIEW — drafts, risks, and ambiguous items needing judgment
3. WATCH — upcoming items with no current action
4. NO CHANGE — sources checked with nothing material found
For every item include source, owner, date, confidence, and next action.
Report detected items separately from actions actually completed.
Advance at most one explicitly authorized, reversible internal step.
Do not send, schedule, publish, accept, decline, purchase, change access,
or delete anything.
```
Use a stable format so each run can be compared with the last.
## Example
For example, a design leader has three upcoming reviews, a project registry, and a selected set of messages. The morning scan finds one explicit promise to share a draft by Wednesday, one meeting whose pre-read has changed, and six unread messages with no request.
The brief places the promised draft in `ACT`, the changed pre-read in `REVIEW`, and ignores unread count as a priority signal. ChatGPT Work assembles the approved sources for the draft and creates a private outline. It does not send the document or modify the calendar.
The next scan reports that the draft is awaiting review and that no new commitments were found.
## Approval boundary
The loop may inspect only configured sources and prepare internal artifacts within its permission scope. It must not infer consent from urgency, calendar proximity, or a previous similar action.
Require explicit approval before sending or replying, scheduling or rescheduling, accepting or declining invitations, publishing, changing project ownership, granting access, purchasing, or deleting. Sensitive sources may require additional policy and consent checks.
Connecting accounts, installing integrations, configuring permissions, and activating recurring scans are separate administrative actions. A copied prompt alone does not establish them.
## Validation
Review a sample of included and excluded items:
- Each item traces to a current source.
- Commitments are explicit or clearly labeled as inferred.
- Deadlines preserve timezone and source wording.
- Rankings follow the stated rules rather than unread volume.
- The brief avoids duplicating already completed asks.
- Existing work stays open until completion is independently verified.
- The internal action is bounded, reversible, and useful.
- Detected, blocked, review-ready, and actually advanced work stay distinct.
- No-change runs name the sources and window checked.
- Outbound and consequential actions remain pending approval.
Track false positives and missed commitments over several cycles before expanding the scope.
## Failure modes
The system can become an anxiety engine if it converts every message into work. Unread does not mean urgent, mention does not mean ownership, and a meeting does not always require preparation.
Other failures include scanning everything without consent, inventing deadlines, repeatedly surfacing stale items, drafting duplicate replies after an answer already exists, and silently changing priorities. A beautiful daily brief can still be wrong if sources are stale.
Avoid “helpful” unbounded follow-ups. When nothing material changed, return a no-change receipt. When priority rules conflict, ask for a decision rather than resolving organizational tradeoffs from weak signals.
---
# 6. Chief of Staff
_advanced | See what needs your attention, what is already moving, and which decision is yours._
## Outcome
Spend less time piecing together updates from different projects. A Chief of Staff workflow gives you one home base to review priorities, follow-ups, and the decisions that need you while each project keeps its owner.
This is an optional way to organize work in ChatGPT Work, not a separate product that turns on automatically. Start with a manual review of sources you approve. Add scheduled checks only when the tool supports them and you explicitly approve the schedule.
Keep four responsibilities distinct:
- **Detect:** find real requests, changed plans, and commitments in approved sources.
- **Incubate:** find the existing owner and prepare one bounded next step for review.
- **Collaborate:** follow one active conversation only when you explicitly ask, for an agreed time.
- **Reflect:** learn from completed work and propose a useful improvement.
You get a clear next step, its supporting source, and an honest status. Finding a request does not mean the work has started or finished. You still verify the sources and approve consequential actions.
Chapter 5 describes the personal home-base experience. This chapter describes the four-role coordination pattern behind it. Chapter 7 supplies the permissions and stopping conditions. None of these patterns grants product access, creates an automation, or authorizes external action.
## When to use it
Use the loop after individual workflows are already reliable. A team with unclear sources or no verified owner should fix those foundations first. Begin with a manual review queue before enabling any schedule.
If scheduling is available and approved, combine Detect and Incubate in one weekday check. Use Collaborate only for a named conversation, owner, and agreed time window. Review completed work with Reflect on Friday or when you ask; keep it separate from checks for new requests.
Not every request needs every role. A no-change detection run should not manufacture a task, and an item with an unclear owner should stop for review.
The [one-time work brief](/prompts#day-desk-four-roles) is a manual starting exercise. Its Collaborate step prepares a handoff once; it does not start the time-limited conversation check described below.
## Operating pattern
Use one weekly home-base task, one approved source map, and at most one scheduled weekday check (the intake controller):
1. **Start with a current run record.** Verify the allowed time window, approved sources, active controller, and human owner.
2. **Detect.** Read only the named sources and attach current evidence to each real request.
3. **Check continuity.** Look for the existing workstream owner without creating duplicates or treating a stale summary as proof.
4. **Incubate.** Prepare an approval-ready next step, or perform at most one specifically authorized internal action.
5. **Record the result.** Distinguish detected, blocked, waiting, review-ready, and actually advanced work.
Collaborate is started separately by the user when one active task needs one bounded conversation monitored. It defaults to reading or preparing text for review and expires when its purpose or time window ends. Reflect happens separately on Friday or on request and uses completed run records rather than scanning new sources.
Optional overnight work is a separate approved plan, not an exception to daytime safeguards. Name the exact objective, resources, allowed actions, stop condition, and morning output; do not execute until a person approves that specific plan.
## Copyable implementation
```markdown
# Chief of Staff run contract
Home-base task: [one existing weekly task]
Cadence/window: [when and what period]
Approved sources: [explicit list]
Routing rules: ignore | watch | review | act
Owners and escalation path: [roles]
Existing-owner lookup: [approved task or project registry]
Allowed internal action: [one explicitly authorized, reversible step]
Approval-required actions: [explicit list]
## Output
- Signals with source, date, owner, confidence, and reason
- Existing-owner decision and duplicate check for each signal
- Review-ready next step or one verified internal action
- Separate detected, actually advanced, blocked, and waiting states
- Verified completion evidence or named blocker
- No-change receipt when appropriate
- Friday or on-demand Reflect proposal, never a silent change
```
Keep a fresh run receipt for every wake. Do not run independent schedules for each role, ask the controller to inspect itself during a scheduled wake, or reuse yesterday's evidence to authorize a new action.
## Example
For example, a team receives a request to update its monthly forecast. Detect verifies the request in an approved source and records the deadline. Incubate checks the project registry, finds an existing forecast task, and prepares the relevant source list instead of opening a duplicate.
The Chief of Staff reports one request detected and one review-ready next step. It does not claim that the forecast changed. If a person explicitly authorizes a bounded continuation, the next run records the action actually taken and leaves the request open until the project owner confirms the result.
If clarification is needed, the user may start a temporary Collaborate session for that one conversation. On Friday, Reflect reviews the completed receipts and proposes a narrower routing rule. No message is sent and no live source changes without approval.
## Approval boundary
This Chief of Staff pattern is not blanket authority or a promised standalone product feature. Installing a Skill, configuring sources, authenticating connectors, granting permissions, scheduling runs, and activating a workflow are separate steps with separate evidence.
Default authority is read-only inspection and a review-ready recommendation. Any internal task advancement needs its own scoped authorization. Require explicit approval for outbound messages, commitments, calendar responses, publication, deployment, purchases, access changes, destructive actions, policy changes, and decisions assigned to a person.
Collaboration does not transfer authority merely because context was handed off. Overnight execution never follows from installing a plugin, approving a prior run, or leaving a plan unanswered.
## Validation
Test the modules independently before testing the loop:
- Detect returns traceable signals and valid no-change results.
- Incubate finds the existing owner and rejects unclear or duplicate work.
- A scheduled run performs no more than one specifically approved internal action.
- Collaborate stays within one owner, one conversation, and one approved time window.
- The receipt separates completed, review-ready, blocked, and detected-only state.
- Reflect uses completed evidence and proposes changes without applying them.
- An overnight plan remains inactive without exact human approval.
Then run scenarios for stale sources, unavailable connectors, duplicate signals, conflicting owners, missed deadlines, unauthorized requests, and no material change. Confirm the system fails closed and leaves a recovery path.
## Failure modes
The largest risk is confusing coordination with authority. A system that can detect a deadline should not automatically commit a person to it. A conversation relay should not strip away caveats or impersonate its owner.
Other failures include several controllers writing conflicting state, repeated scans creating duplicate work, a scheduler querying its own running task, reflection silently rewriting policy, and counting detected requests as completed work. Broad source access also increases privacy and security risk.
Keep one canonical registry, stable run identifiers, and an explicit owner for each state transition. If a module cannot verify source, permission, or ownership, it should stop, preserve evidence, and request review.
---
# 7. Let ChatGPT Work help without giving up control
_advanced | Let ChatGPT Work prepare the next useful step while you keep approval over sending, sharing, publishing, and other important actions._
## Outcome
Choose a recurring check, the sources it may read, and the draft or next step you want it to prepare. Review the result before approving further action.
A bounded proactive system knows its sources, cadence, permitted actions, stopping conditions, and owner. It can return “no change” when nothing deserves attention. It also leaves enough evidence that another person, or a fresh task, can understand what happened.
Proactivity is an explicitly configured pattern, not proof that any particular account supports scheduled tasks, connected applications, background monitoring, or unattended work. Confirm the available capability and obtain approval before activating it.
## When to use it
Use bounded proactivity when a workstream has recurring signals and a predictable safe response: reviewing an intake queue, spotting unanswered requests, preparing a meeting packet, checking whether a deliverable is stale, or advancing the next internal step in a documented workflow.
It works best when inputs have a canonical location and the next step can be made reversible and reviewable. Keep the human closer when the work involves ambiguous ownership, legal or personnel judgment, sensitive data, external communication, publication, spending, access control, or irreversible changes.
Do not automate a process merely because it occurs often. First make sure that a competent person can explain the process, exceptions, and proof of completion.
## Operating pattern
Define a compact control loop:
1. **Detect:** Read only the named sources and identify eligible signals.
2. **Verify:** Confirm currentness, ownership, and whether the signal has already been handled.
3. **Prioritize:** Rank by consequence, deadline, dependency, and reversibility, not by how alarming the language sounds.
4. **Advance:** Take one bounded internal action, such as drafting, organizing, calculating, or assembling evidence.
5. **Review:** Present the result, sources, uncertainties, and proposed next action to the accountable human.
6. **Close or checkpoint:** Record what changed, what remains, and when the loop should run again.
7. **Reflect:** Capture repeated corrections as a candidate improvement to instructions or a Skill.
Set a work-in-progress limit. One completed, reviewable intervention is usually more valuable than six partially explored opportunities. A scan that finds nothing actionable should say so and stop.
Treat a heartbeat as a bounded check-in, not permission to watch everything. Name one task or source, its cadence, expiry, owner, and stopping condition. Prefer one controller for a workstream, keep owner lookup separate from the running scheduler, and write a fresh receipt for each run. A prior receipt may explain history; it cannot prove the current source or authorize a new action.
Screenshots, an active application view, and computer-history context are optional and capability-dependent. Use them only when the person explicitly approves the application, question, and time window; never expand into unrelated activity, background collection, credentials, or private conversations.
## Copyable implementation
```markdown
# Proactive loop contract
Objective: Keep [workstream] moving without external or irreversible action.
Owner: [human role]
Cadence: [manual / daily / weekly / event-triggered]
Expiry or stop condition: [exact time, completed decision, or user stop]
Existing-owner lookup: [approved workstream registry]
Canonical sources:
- [source and what it proves]
- [source and what it proves]
Eligible signals:
- [specific condition]
- [specific condition]
Allowed actions:
- Read and organize source material.
- Draft an internal artifact for review.
- Advance at most one explicitly authorized, reversible step named in this contract, including its target and scope. If that approval is missing, return a draft or proposed next step only.
- Create a checkpoint when the work cannot finish safely.
Always require approval for:
- Sending or posting messages.
- Publishing or deploying.
- Changing access, permissions, or records.
- Spending money or making commitments.
- Destructive or hard-to-reverse changes.
Output:
- Signal found, or "no change."
- Evidence and currentness.
- Existing owner and duplicate-check result.
- Run receipt, observed time window, and approval state.
- Action taken.
- Open questions and risks.
- Approval-ready next step.
Stop when:
- Ownership is unclear.
- Sources conflict or are stale.
- The next action crosses an approval boundary.
- The intervention limit has been reached.
```
## Example
For example, a strategy team reviews a weekly request queue. The loop finds three open items. One is already answered in the canonical tracker, one has no named owner, and one has a deadline in two days with all required inputs present.
ChatGPT Work ignores the completed item, flags the owner gap without assigning it, and advances the third item by assembling the relevant sources and drafting an internal recommendation. It does not send the recommendation. Its output identifies the deadline, links the evidence, labels one assumption, and asks the accountable manager to approve or revise the draft. The scan closes with one intervention and a clear no-action explanation for the other two.
## Approval boundary
Read and prepare only within the scope the user has approved. Urgency never expands authority. A looming deadline may change prioritization, but it does not authorize an external message, a production change, a financial commitment, or a deletion.
Write the boundary in operational terms. “Use good judgment” is not a control. “Draft the reply, cite its sources, and wait for approval before sending” is.
## Validation
Test the loop with normal, empty, duplicate, stale, conflicting, and urgent inputs. Confirm that it:
- Uses only named sources and reports their currentness.
- Uses one explicitly approved heartbeat or controller with a real stop condition.
- Finds the responsible owner rather than silently becoming the owner.
- Selects no more than the permitted number of interventions.
- Separates detected requests from actions actually completed.
- Produces a useful “no change” result.
- Stops before every approval-gated action.
- Leaves a checkpoint that a new task can resume.
Review false positives and missed signals after several runs. Adjust the signal definition before increasing autonomy.
## Failure modes
Common failures include treating every unread item as work, confusing urgency with permission, scanning indefinitely, creating duplicate tasks, reusing stale receipts, inspecting the scheduler from inside its own run, and producing activity without a decision-ready result.
Another failure is “helpful” ownership drift: ChatGPT Work starts filling gaps that belong to a named person or team. Prevent this by requiring an owner field and a stop condition for unclear ownership. Finally, do not reward the loop for always finding something. A trustworthy system is allowed to conclude that nothing needs intervention.
---
# 8. Move work between the tools you already use
_intermediate | Connect messages, documents, spreadsheets, slides, and sites without losing track of the original source or who needs to approve the work._
## Outcome
Where the required tools are available and approved, ChatGPT Work can help with a task that spans applications. Identify the source for each claim and link the resulting document, spreadsheet, or presentation back to it.
Check source dates before reusing information and review the result in its destination app. Get approval before changing a shared source or publishing the result.
## When to use it
Use this pattern whenever a deliverable crosses two or more applications. For example, a request arrives in an approved messaging tool, source material lives in documents and spreadsheets, a decision is scheduled in a calendar, the result is presented in slides, and a reusable workflow becomes an approved shared application.
It is especially valuable for recurring reviews, meeting preparation, reporting, operational intake, and tool building. For a simple one-off task in one document, keep the workflow simple.
Before connecting surfaces, identify which application is authoritative for each kind of fact. A chat message can route work, but it should not silently replace the maintained tracker or signed-off document.
## Operating pattern
Start with a source map. For each application, define:
- Its role in the workflow.
- The artifact or field that is authoritative.
- The owner and expected freshness.
- What may be read automatically.
- What may be drafted locally.
- What requires explicit approval to change.
- How downstream artifacts point back to evidence.
Then follow a read–transform–review–act sequence. Re-read the live source immediately before using mutable facts. Transform material into a draft while preserving citations, units, dates, and uncertainty. Review the draft in the destination’s actual format. Act only when the required human approves the specific external mutation.
Prefer links and compact handoffs over pasting large copies between tools. When an artifact becomes recurring and interactive, consider promoting it to a Site or application, but keep its data contract and approval model explicit.
## Copyable implementation
```markdown
# Cross-application workflow map
Workflow: [name]
Decision owner: [role]
| Surface | Role | Canonical artifact | Freshness | Allowed action |
|---|---|---|---|---|
| Chat | Intake and discussion | [channel/thread] | [observed timestamp and currentness rule] | Read; draft reply |
| Calendar | Time and attendance | [event] | [observed timestamp and currentness rule] | Read; propose change |
| Docs | Narrative source | [document] | [rule] | Read; draft locally |
| Sheets | Structured source | [sheet/range] | [rule] | Read; analyze |
| Slides | Decision presentation | [deck] | [rule] | Draft; preview |
| Site/App | Reusable experience | [project] | Versioned | Build locally |
Mark unknown or stale coverage explicitly. These surface roles and action examples do not establish access or authorization.
Handoff contract:
- Source facts and timestamps:
- Transformation performed:
- Assumptions:
- Destination artifact and state:
- Required reviewer:
- External action awaiting approval:
```
## Example
For example, an operations team prepares a monthly review. A chat thread contains the request, a calendar event establishes the deadline, a document holds qualitative updates, and a spreadsheet contains the maintained measures.
ChatGPT Work reads the event and live sources, reconciles dates and labels, and creates a local presentation draft. It places source references in speaker notes and marks one missing update as pending. After a human reviews the deck, the team decides that the repeated assembly work deserves a small internal Site. The Site reads a versioned, public-safe sample dataset during development; connecting live data remains a separate approved implementation step.
## Approval boundary
Reading connected sources does not authorize changing them. Drafting a message does not authorize sending it. Building a local Site does not authorize deployment. Creating an application package does not authorize installation, access changes, or activation.
Require specific approval for outbound messages, calendar invitations or responses, edits to shared artifacts, permission changes, deployment, publication, and connections to live systems. Preserve the exact draft or version that was approved; a later revision needs another review if the change is material.
## Validation
Validate both content and surface behavior:
- Re-read mutable sources immediately before finalizing the draft.
- Confirm owners, dates, units, and definitions across applications.
- Verify that links resolve for the intended audience.
- Preview Docs, Sheets, Slides, and Sites in their rendered form.
- Test empty, stale, missing, and conflicting source states.
- Confirm the destination clearly displays draft, reviewed, deployed, or published state.
- Check that copy, export, and handoff paths retain source attribution.
For applications, also test permissions, error states, keyboard use, responsive layout, and recovery after an interrupted run.
## Failure modes
The most common failure is state collapse: a local draft is described as live, an installed package is described as active, or a successful build is described as deployed. Another is source laundering, where a copied value loses its date, owner, or definition as it moves through applications.
Watch for silent live edits, duplicated data stores, broken links, inaccessible artifacts, and “automation” that depends on a person manually repairing the output every run. Avoid connecting every tool merely because it is available. Each connection adds permissions, failure modes, and maintenance; it should earn its place in the workflow.
---
# 9. Know what is current, checked, and approved
_advanced | Tell the difference between a draft, a checked result, and something that is actually ready to share._
## Outcome
A report can pass its checks and still be out of date. Before sharing it, check the source date, the tests completed on this version, and the approval required for the next action.
Record what exists, what you checked, what remains uncertain, and who approves the next step. Use the precise status definitions below when a result has several versions or destinations.
## When to use it
Use this model for any work that can be reviewed, shared, uploaded, deployed, or published: analyses, documents, dashboards, presentations, application packages, websites, automations, and recurring reports.
It matters most when several surfaces exist at once: a source file, generated output, local preview, hosted review, staging candidate, and live destination. It also matters when the input data changes faster than the artifact. Even a small team benefits from this discipline once “ready” can mean different things to different people.
Use lighter labels for low-stakes personal notes. Do not create ceremony that exceeds the cost of being wrong.
## Operating pattern
Track three axes separately.
**Currentness** answers: When were the canonical sources last read, what period do they cover, and what could have changed since then?
**Lifecycle** answers: What checks did this exact artifact revision pass? A useful progression is:
- `draft`: incomplete or not yet validated.
- `validated`: named checks passed for this revision and surface.
- `release_candidate`: a clean candidate exists, but one or more approval, packaging, currentness, or target-surface gates remain.
- `release_ready`: every named release contract is proven.
- `published`: the intended live target was updated and verified.
**Authorization** answers: What is the agent or operator allowed to do next? Read, draft, edit locally, change a shared artifact, deploy, publish, and alter access are separate permissions.
Every state transition should cite evidence, name the actor, and preserve the prior revision or recovery path.
Apply the same discipline to orchestrated work. A request can be `detected`, `owner_verified`, `review_ready`, `advanced`, `blocked`, or `complete`; those labels are not interchangeable. A fresh run receipt should name the source observation, existing owner, permitted action, action actually taken, outstanding approval, and completion evidence. Finding a task does not mean starting it, and starting it does not mean finishing it.
## Copyable implementation
```markdown
# Artifact state receipt
Artifact: [name and revision]
Owner: [role]
Intended destination: [surface]
Currentness:
- Canonical sources:
- Read at:
- Period covered:
- Known freshness gap:
Lifecycle:
- Current state: draft | validated | release_candidate | release_ready | published
- Checks passed:
- Checks not run or failed:
- Exact revision/checksum:
Authorization:
- Allowed now:
- Requires approval:
- Approver:
Run evidence, when applicable:
- Source observed at:
- Existing owner verified:
- Action authorized:
- Action actually taken:
- Completion independently verified:
Next transition:
- Proposed action:
- Evidence required:
- Verification after action:
```
Adopt one invariant: state is proven by evidence, not inferred from a filename, folder, previous release, successful command, or confident summary.
## Example
For example, a planning team generates a quarterly briefing from a maintained workbook. The workbook was read Monday; on Tuesday, the owner adds a revised forecast. The briefing’s formatting and calculations passed their checks, so the artifact is still `validated` for the revision tested, but it is no longer current for the intended decision.
ChatGPT Work reports: “Validated against Monday’s source; currentness gap remains after Tuesday’s update.” It refreshes a local draft, reruns the named checks, and prepares a release candidate. It does not replace the shared briefing until the accountable owner approves that exact revision. After replacement, it opens the destination and verifies the version before using `published`.
## Approval boundary
Validation is not authorization. A release-ready bundle may still require a human decision to deploy. Approval of a concept is not approval of every future revision, and access to a system is not permission to change it.
Require explicit approval for shared edits, uploads, deployments, publication, access changes, external messages, and destructive operations. The approval request should name the exact artifact, revision, destination, material changes, residual risks, and recovery method.
If a source changes after approval but before publication, stop and reassess currentness. Do not silently treat the prior approval as covering a materially different result.
## Validation
Test the state model against realistic edge cases:
- A validated artifact with newly stale sources.
- A current source feeding an unvalidated transformation.
- A release candidate missing destination permissions.
- A successful deployment whose live route shows the prior version.
- A published artifact with a broken dependency.
- An approved revision that changes before action.
- A detected request that has not started or obtained approval.
- A resumed task whose output has not yet passed its completion checks.
Confirm the receipt identifies exact evidence and never uses “ready” without its qualifier. Verify the live destination after publication; command success alone is insufficient.
## Failure modes
Typical failures include calling a directory “final,” treating a clean build as deployment proof, carrying currentness forward from an earlier run, and confusing access with authorization. Another is collapsing multiple surfaces: editor state, generated output, local preview, hosted review, and published output are described as if they were identical.
Avoid vague traffic-light labels without definitions. “Green” does not say which checks ran or which source period was used. Finally, do not let receipts become stale paperwork. Generate them from the same revision and validation run whenever possible, and make missing evidence block the stronger claim.
---
# 10. Help a team work together without losing ownership
_advanced | Connect people, projects, and tasks while keeping the right owner, trusted sources, and human approvals clear._
## Outcome
Divide independent work among people or tasks, with one owner for each part. Name one person to combine the results and check them against the agreed sources and requirements.
For collaboration between tasks, where supported, give each task its inputs, expected output, permitted files or systems, and checks. The responsible person reviews the combined result and approves release.
## When to use it
Use a team operating system when work spans distinct specialties, repositories, artifacts, or review lanes. Good candidates include a research–analysis–presentation pipeline, a source-data producer feeding a dashboard consumer, or parallel preparation of independent sections against locked inputs.
Do not split a small, tightly coupled edit merely to appear parallel. Avoid parallel work when the source of truth, shared schema, or common renderer is still changing. Resolve the dependency first, then delegate independent packages.
Use explicit handoffs whenever another person or task must rely on an output without reconstructing the original context.
## Operating pattern
Start with one accountable integration owner. That owner locks the objective, source contracts, shared interfaces, and release boundary. Then define work packages with:
- A bounded goal and non-goals.
- Canonical inputs and their currentness.
- Output location and format.
- Exclusive file or artifact ownership.
- Allowed and prohibited actions.
- Acceptance tests and evidence.
- The next owner and approval gate.
Parallelize only packages that can proceed independently from locked inputs. No two tasks should edit the same file or shared live artifact. When a package completes, its handoff should carry facts and proof, not just a narrative that the work went well.
The receiving task validates the handoff before consuming it. Missing, stale, incompatible, or unverifiable inputs should block the dependency rather than trigger silent repair.
## Copyable implementation
```markdown
# Work package
Goal: [one bounded result]
Owner: [person or task]
Integration owner: [role]
Inputs:
- [canonical source, revision, currentness]
Owned outputs:
- [exclusive artifact or path]
Non-goals:
- [shared interface or adjacent work not to change]
Allowed actions:
- [read, analyze, edit bounded files, run named checks]
Approval-gated actions:
- [shared edit, send, deploy, publish, access change]
Acceptance:
- [test or review criterion]
- [required evidence]
Handoff:
- Result and exact revision:
- Checks run:
- Known gaps and risks:
- Assumptions:
- Recommended next owner/action:
```
Use a stable project index to point to current packages, handoffs, and decisions. The index should link to the evidence rather than duplicate it.
## Example
For example, an insights team must produce a public report and companion interactive experience. The integration owner locks a public dataset schema and editorial rules. One task analyzes the dataset read-only, another writes narrative sections in separate files, and a third builds the interface against test fixtures.
Each task owns disjoint outputs. The analysis handoff includes the dataset revision, calculations, and tests. The writing task distinguishes sourced claims from interpretation. The interface task demonstrates empty and error states without connecting live systems. The integration owner validates all three outputs, resolves conflicts, and prepares one review candidate. No worker publishes or changes access.
## Approval boundary
Delegation does not transfer accountability. A subtask may prepare a result but cannot expand its scope, change a shared contract, or take an external action unless that authority is explicit.
Keep source-of-truth decisions, shared schemas, integration, deployment, publication, and readiness claims under one owner. Require human approval for outbound communication, production changes, access or permission changes, spending, legal commitments, and destructive actions.
If a receiving task discovers that an input is wrong, it should return the issue to the producer or integration owner rather than silently rewriting producer-owned facts.
## Validation
Before dispatch, confirm that inputs are locked and ownership is disjoint. At handoff, verify:
- The exact source and output revisions.
- Required tests and their results.
- Schema, grain, units, or interface compatibility.
- No prohibited shared files or systems changed.
- Open assumptions and failures are explicit.
- The next owner can resume without conversational history.
Run an end-to-end integration check after assembling packages. Passing package tests does not prove the combined system works.
## Failure modes
Common failures include parallel edits to the same artifact, delegation before inputs stabilize, vague “research this” assignments, and handoffs that omit evidence. A swarm can produce more text while making the decision harder.
Other risks are ownership laundering and silent repair. ChatGPT Work should not become the de facto owner because the real owner is unavailable, and consumers should not alter upstream definitions to make their own output pass. Finally, avoid permanent coordination overhead. If a handoff costs more than the task, keep the work sequential and under one owner.
---
# 11. Pick the work back up where you left off
_intermediate | Keep a clear checkpoint so a new conversation, teammate, or device can continue the work without starting over._
## Outcome
Save enough context to resume after an interruption: the objective, current result, sources, decisions, open risks, and next step. Use the same checkpoint when handing work to another person or task.
Continuity is more than keeping a process awake. It combines frequent checkpoints, restartable steps, versioned artifacts, tested backups, and concise recovery instructions. The best recovery experience does not depend on reconstructing a long conversation.
Be precise about what follows a user to another device. A project backup can preserve files and written instructions, but it does not automatically recreate local account connections, app permissions, task schedules, credentials, running processes, or machine-specific settings. Verify each dependency separately before claiming a recovered workflow is active.
## When to use it
Use this pattern for any task that lasts longer than a focused sitting, changes important files, depends on external systems, has multiple validation stages, or may be handed to another person or task.
Checkpoint more aggressively before deployments, bulk transformations, travel, device migration, long unattended runs, or work with expensive source reads. A brief one-off draft may need only a saved file and a clear name.
Treat continuity as a design requirement before the work begins. A backup created after an incident is not a recovery plan.
## Operating pattern
Build continuity in five layers:
1. **Atomic steps:** Split work into bounded stages that can be rerun safely.
2. **Checkpoints:** After meaningful milestones, record verified state and the next action.
3. **Versioned outputs:** Keep source inputs, generated artifacts, and validation receipts identifiable.
4. **Backups:** Keep a recoverable copy outside the device or storage location that holds the working files, using an approved destination. Verify that the copy is intact.
5. **Recovery rehearsal:** Periodically restore to a clean location and prove that instructions work.
A checkpoint should be small enough to read quickly and precise enough to resume without the original conversation. Record facts separately from assumptions. Name incomplete or failed checks explicitly.
Preserve the existing workstream owner when resuming. Check the canonical project, current source revision, outstanding approvals, and latest run receipt before creating a new task. If identity or source access cannot be verified on the current device, stop at a review-ready recovery plan rather than guessing.
Automations should be idempotent where practical: rerunning the same stage does not duplicate messages, corrupt state, or overwrite a newer result. Use temporary outputs and promote only after validation.
## Copyable implementation
```markdown
# Restart card
Goal: [single objective]
Owner: [role]
Last verified at: [timestamp and time zone]
Verified current state:
- [artifact/revision and evidence]
- [check passed and result]
Decisions locked:
- [decision and rationale]
Incomplete or unverified:
- [gap, failed check, or dependency]
Connections and schedules:
- Approved source access verified: [yes / no / not tested]
- Existing owner or task verified: [yes / no / not tested]
- Any recurring schedule verified: [yes / no / not configured]
Resume in this order:
1. Re-read [canonical source].
2. Confirm [currentness or dependency].
3. Run [bounded next step].
4. Validate with [named check].
Do not:
- [external, destructive, or stale-state action]
Approval required before:
- [send, publish, deploy, access change, destructive action]
Recovery locations:
- Primary artifact: [portable pointer]
- Backup: [portable pointer and backup date]
- Integrity check: [method]
```
Create a fresh card when the goal changes, the work changes lanes, or three substantial implementation or validation checkpoints have passed.
## Example
For example, a research group builds a recurring briefing from several public datasets. Each run writes to a new versioned directory, records source retrieval times, and validates the combined output before updating a `latest` pointer. After analysis and layout milestones, ChatGPT Work refreshes the restart card.
During an interrupted run, a new task reads the card, confirms that the sources have not changed, and reruns only the incomplete layout stage. It does not repeat the analysis or publish the briefing. Later, the team rehearses recovery by restoring the project backup into a clean temporary location, rebuilding the briefing, and comparing checksums for stable inputs.
## Approval boundary
Permission to checkpoint or back up local work does not authorize copying sensitive material to an unapproved destination. Storage location, retention, encryption, and access policy remain human and organizational decisions.
Require approval before overwriting shared state, restoring over a current workspace, changing backup retention, exporting restricted data, publishing recovered artifacts, or deleting old versions. During recovery, default to restoring into a separate location and comparing before replacement.
## Validation
Prove continuity rather than assuming it:
- Resume from the restart card in a fresh task.
- Verify existing ownership, source permissions, and any approved schedule independently.
- Interrupt a non-destructive test run and rerun the incomplete stage.
- Confirm reruns do not duplicate external actions.
- Restore a backup into a clean location.
- Verify expected files, metadata, and integrity checks.
- Confirm secrets and restricted data are excluded or handled by approved controls.
- Measure recovery time and record missing instructions.
Validate both the artifact and its dependencies. A restored project that cannot locate its required runtime or source contract is not fully recoverable.
## Failure modes
Common failures are giant checkpoints that merely copy chat history, backups that were never restored, a `latest` folder with no provenance, and scripts that overwrite their only good output. Another is confusing synchronization with backup: synchronized corruption or deletion can propagate everywhere.
Watch for restart cards that claim checks passed without evidence, recovery instructions tied to one person’s machine, assumed account or scheduler migration, and unattended runs whose external side effects are not idempotent. Finally, do not let continuity become indefinite accumulation. Use an approved retention policy, but delete only with clear scope and recovery awareness.
---
# 12. Keep longer work safe and recoverable
_advanced | Continue approved work through clear checkpoints, bounded handoffs, and separately approved overnight plans._
## Outcome
Decide whether a follow-up should change the current run or wait until it finishes. Before stepping away, record the task, approved inputs, owner, permitted actions, time limit, stopping condition, and checkpoint needed to resume.
Some environments may support approved remote review, scheduled tasks, or unattended execution; others may not. Verify what is actually available before planning around it. Optional overnight work begins only after a person approves that specific plan and its resource limits.
## When to use it
Use this pattern for a clearly defined analysis, non-destructive test run, local draft, evidence review, or other work that may span an interruption. Begin only when the owner, approved sources, expected result, and review boundary are known.
Prefer an ordinary manual checkpoint when the task needs frequent judgment, relies on unavailable connections, or could affect another person. Consider an approved scheduled or overnight run only when the actual environment supports it and the job can fail safely.
Do not assume a task follows you to another device, a connection stays available, or a background process keeps working. Verify the execution surface and recovery path independently.
## Queue vs steer
While a run is underway, choose whether your next message should change the current work or wait.
- **Steer** adds a correction or direction to the current run. For example: “Use this corrected workbook instead.”
- **Queue** saves a follow-up for the next run. For example: “When you finish, draft the email for my review.”
In the desktop app, choose the default under **Settings → General → Follow-up behavior**. That setting also shows the shortcut for using the other behavior for one message. Queued messages appear above the composer, where you can edit, reorder, or remove them.
These controls do not enable tools or expand access. Sending or publishing still needs your approval. See the [official Queue and Steer guidance](https://learn.chatgpt.com/docs/prompting#steering-and-queuing).
## Operating pattern
If local work needs your Mac to stay awake, you can turn on **Prevent sleep while running** in settings, where available. Keep the Mac plugged in and connected to any network the task needs. Save a checkpoint and a clear stop condition before stepping away, then review the result. See the [long-running work guide](https://learn.chatgpt.com/docs/long-running-work).
Use one existing work owner and one bounded execution plan:
1. **Name the job.** Record the desired result, intended audience, existing project, and human owner.
2. **Verify the starting state.** Read the approved source, current checkpoint, connected-tool availability, and exact work authorization.
3. **Define the boundaries.** List permitted files, tools, resource limits, review gates, and actions that remain prohibited.
4. **Preserve recovery.** Write a concise restart card before the first meaningful step and update it at material milestones.
5. **Approve optional unattended work.** Present the exact objective, duration, permitted actions, stop condition, and expected report. Start only after explicit approval.
6. **Check real progress.** Compare the current output or run record with the previous checkpoint; an active-looking interface is not evidence.
7. **Stop cleanly.** Finish on verified completion, expiration, unavailable access, uncertain ownership, an approval boundary, or user request.
Never create an additional controller to compensate for an unverified owner. A separately approved overnight plan may continue existing work only within its stated scope; it does not inherit permission to send, publish, deploy, or alter shared systems.
[Record what a heartbeat actually did](/prompts#heartbeat-receipt) when reviewing scheduled work. A receipt should show progress and remaining approval gates, not just that a task ran.
## Copyable implementation
```markdown
# Extended-work plan
Objective: [one bounded operation]
Existing project and owner: [verified workstream]
Approved sources: [named evidence]
Execution mode: manual checkpoint | approved scheduled run | approved overnight plan
Available runtime: [verified environment, not an assumption]
Time and resource limits: [start, expiry, allowed resources]
Permitted actions: [exact internal read or preparation scope]
Prohibited actions: [messages, live edits, access, publishing, deployment]
Before:
- Verify the current source, existing owner, and last known checkpoint.
- Save one restart instruction and the expected acceptance check.
- Confirm the exact approval and an enforceable stopping condition.
During:
- Record what changed, what remains, and any failed check.
- Stop if access, ownership, time, or permission becomes uncertain.
- Keep all external actions pending separate human approval.
After:
- Validate the exact output against the named acceptance check.
- Report completed, blocked, or review-ready state with evidence.
- Preserve the recovery checkpoint and outstanding approvals.
```
An example plan is not itself approval, a running schedule, a connected account, or proof of a completed task.
## Example
For example, a project lead needs a comparison of three approved public research documents before the next morning. The existing research task already contains the objective, source list, quality checks, and a partially completed outline.
The lead asks for an overnight plan covering only those documents, one local draft, a fixed end time, and a short morning summary. The plan prohibits outbound messages, changes to shared documents, new account connections, and unrelated browsing. Work begins only after the lead approves that exact scope.
The next morning, the result identifies which sources were actually read, which sections remain uncertain, and whether the draft passed its checks. If a source became unavailable overnight, the task remains blocked with a restart card rather than pretending the analysis is complete.
## Approval boundary
Longer runtime never expands the authority granted to the original task. Sending, posting, publishing, deploying, editing shared artifacts, changing permissions, spending money, and destructive operations each require their own explicit approval.
Do not bypass device management, security controls, organizational policy, or account restrictions. If the available environment cannot enforce the approved time, scope, or stopping condition, do not start unattended work.
## Validation
Verify separate claims rather than replacing evidence with a reassuring status light:
- **Ownership:** the existing project and accountable person are confirmed.
- **Sources:** each permitted input is current and within scope.
- **Availability:** the approved execution environment actually supports the planned run.
- **Approval:** the exact objective, resources, and prohibited actions were authorized.
- **Progress:** a fresh receipt shows what changed, not merely that a task exists.
- **Recovery:** a new task can continue from the latest checkpoint.
- **Stop condition:** expiration, uncertainty, completion, or user interruption halts the run.
- **Output quality:** the final artifact passes its named acceptance checks.
If any claim is missing, label the result blocked, partial, or review-ready as appropriate.
## Failure modes
Common failures include treating a planned run as an active one, assuming another account or device has the same capabilities, confusing a visible task with verified progress, and relying on yesterday's approval for a materially different job.
Other failures are starting a second controller, losing the existing owner, scanning unrelated sources, overriding normal device safeguards, silently changing shared work, or calling an unfinished draft complete. A process that cannot explain its evidence and stopping condition is not ready to continue unattended.
Prefer a short checkpoint and a clear human decision over an elaborate workaround. Reliable continuity comes from ownership, evidence, bounded permission, and recovery.
---
# 13. Build one reliable workflow in 30 days
_beginner | Start with real work, draft while the context is fresh, test new examples, and stay in control._
## Outcome
In 30 days, aim to build one project with the right context, one workflow you can repeat, and a clear way to review the result. If the work calls for a Skill, draft it while your real example and corrections are still in context. Test that draft on new examples before you rely on it. Finishing a Skill or an automation on a calendar deadline is not the goal.
The point is to get more useful work done without giving up control. By the end, a fresh task should be able to understand the job, find the right sources, pick up the next step, and show you what still needs your approval.
## When to use it
Use this plan when you have experimented with ChatGPT Work but your work still depends on one-off prompts, scattered tasks, or repeated context rebuilding. It also works for a team lead who wants a small, governed pilot before broader adoption.
Choose one durable, recurring workstream with accessible sources and a human owner. Avoid beginning with the most sensitive, politically ambiguous, or production-critical process. A good first project runs weekly or monthly, produces a reviewable artifact, and has a clear definition of done.
Budget thirty to sixty focused minutes on most weekdays, plus one deeper validation session each week.
## You do not have to start from zero
- **Beginner:** Start at Week 1 with one piece of work you repeat. Share the background before worrying about Skills or automation.
- **Intermediate:** Start with the first missing step. If your project and sources are in place, check that a fresh task can use them and move on.
- **Advanced:** Keep what works. Use the self-audit to find missing context, review steps, or recovery notes.
## Operating pattern
Build the workflow in four practical weeks. Move forward when the work is ready, not just because the calendar changed.
**Days 1–7: Complete real work and capture what helped.** Choose one recurring task. Record its owner, trusted sources, audience, and a real example. Complete the work with ChatGPT Work and note what you had to explain or correct. If a Skill would help, draft it before leaving the example and corrections behind. Teaching starts when you share the actual work.
**Days 8–14: Test fresh examples and improve the draft.** Run the workflow and any Skill draft against fresh examples. Improve it when the source, audience, or decision changes. Do not call it reliable after only one result.
**Days 15–21: Add one small, safe assist.** If the workflow is reliable, let ChatGPT Work notice a real change and prepare one next step. It may read and draft, but it cannot send, publish, deploy, change access, or delete without approval. It should also be able to say that nothing needs attention.
**Days 22–30: Make it easy to review and resume.** Record what is current, what has been checked, and what still needs approval. Start a fresh task, see whether it can find the right context, and improve the instructions wherever it gets stuck.
## Resources for each week
Use only the resources your pilot needs. You do not need to complete every template before trying the work.
### Week 1: Set up the context
- [Try one real task](/prompts#first-task)
- [Draft a Skill from the example and corrections](/prompts#skill-draft), if the method is worth reusing
- [ChatGPT Work instructions](/templates#chatgpt-work-instructions)
- [Global working instructions](/templates#global-agents)
- [Project-folder AGENTS.md](/templates#project-agents)
- [Project charter and source map](/templates#project-charter-source-map)
- [Canonical task registry](/templates#task-registry)
### Week 2: Test the workflow
- [Workflow specification](/templates#workflow-specification)
- [Skill specification](/templates#skill-specification)
### Week 3: Add a bounded assist
- [Bounded proactive loop](/guide/bounded-proactivity)
- [Approval and mutation matrix](/templates#approval-matrix)
### Week 4: Make it recoverable
- [Checkpoint and restart card](/templates#checkpoint-restart-card)
- [Continue, pause, or new-task handoff](/templates#task-handoff)
- [Reflect and refine report](/templates#reflect-and-refine)
## Copyable implementation
```markdown
# 30-day installation scoreboard
Pilot workstream: [name]
Human owner: [role]
Decision produced: [artifact or outcome]
Week 1 exit gate:
- The project, trusted sources, owner, and real example are clear.
- One real run is complete and its corrections are recorded.
- If a Skill would help, draft it before leaving the example and corrections behind.
Week 2 exit gate:
- The workflow has been tested on more than one real example.
- Repeated corrections and the human review step are written down.
- Any Skill draft is tested on new examples before it is treated as reliable.
- Missing, stale, and conflicting information are handled safely.
Week 3 exit gate:
- One optional, reviewable next step can be prepared safely.
- It produces useful work or "no change" and stops for approval.
Week 4 exit gate:
- Fresh-task recovery succeeds.
- Artifact state receipt is accurate.
- Backup restore is rehearsed.
- Owner approves the next expansion.
Daily note:
- What worked:
- Correction needed:
- Evidence:
- Candidate instruction or Skill improvement:
```
[Copy the installation prompt](/templates#self-audit-installation) to review your current setup and agree on a starting point.
Do not advance just because seven days have passed. Continue when the work actually proves the next step is useful and safe.
## Example
For example, a program manager chooses a weekly decision brief as the pilot. In week one, they identify the maintained tracker as the canonical status source and meeting notes as supporting context. The first manual run reveals inconsistent project names, so they add a vocabulary table.
Before leaving the first example, the manager drafts a Skill that checks the current tracker, flags a missing owner, and keeps the final recommendation with a person. In week two, they test that draft against fresh briefs and correct anything that does not carry over. In week three, a small scan can find briefs due within three days and prepare one draft at a time. In week four, a new task picks up from the saved checkpoint and recreates the brief. The manager decides whether to expand the workflow; sending remains manual.
## Approval boundary
This guide does not authorize changes. After you approve a specific pilot, the agent may organize local files, draft, test, and analyze only within that approved scope. Outbound messages, shared-document changes, live connectors, deployment, publication, access changes, spending, and destructive actions still require separate approval.
Add permissions one at a time only after the preceding behavior is observable and reliable. Connection availability is not approval. A successful test is not permission to activate a recurring automation.
## Validation
At each weekly gate, use a fresh task or reviewer to prove that the written system is sufficient. Validate:
- Sources, owners, definitions, dates, and currentness.
- Reproducible outputs from the same inputs.
- Explicit handling of missing, stale, duplicate, and conflicting data.
- Human review before every external action.
- Accurate draft, validated, candidate, ready, and published labels.
- A useful “no change” outcome.
- Restart and restore from durable artifacts.
Track correction rate, time to reviewable output, missed exceptions, and unnecessary interventions. Improvement should reduce correction and uncertainty, not simply increase activity.
## Failure modes
The most common failure is trying to install the entire guide at once. This creates elaborate infrastructure before a single workflow is understood. Another is promoting a fragile prompt directly into automation.
Other failures include selecting a pilot with no owner, storing context only in chat, skipping failure-path tests, adding connectors before source contracts, and measuring success by hours saved without measuring review burden or error risk. If a weekly gate fails, narrow the workflow and repair the contract. Do not compensate by granting more autonomy.
---
# 14. Build a Site that becomes part of the work
_advanced | Build a useful Site for a presentation, dashboard, review, or recurring workflow, with clear sources and working controls._
## Outcome
A working Site brings the question, supporting sources, useful tools, and
next decision into one place. Someone should quickly understand what it does,
where to start, and which information to trust.
Start with work that already matters. A presentation, dashboard, monthly
review, or forecast brief needs a different layout and different controls.
## When to use it
Build a Site when the work is recurring, interactive, shared, or easier to
review in one place. Useful cases include presenting a story, exploring data,
reviewing results, tracking decisions, or teaching a workflow.
Keep a document, slide, or spreadsheet when that is all the job needs. A Site
should earn the additional work of maintaining navigation, sources, controls,
access, and a usable mobile experience.
## Operating pattern
Agree on the audience, question, approved sources, owner, and next useful
action. Reuse a supplied working Site or template when it fits. Then build a
clear layout around that job:
- **Header:** Identify the Site, use the supplied branding, and show the
reporting period or review state when relevant.
- **Tabs:** Group the work into useful sections, such as Slides / Notes /
Sources or Summary / Results / Variances / Actions.
- **Toolbar:** Provide working controls for the current task: slide navigation,
filters, scenario selection, editing, or export.
- **Mascot assistant:** Offer a collapsible helper that answers from the
Site's content, links to supporting sources, and says when an answer is
missing.
Keep sources, dates, units, and owners close to the claims they support. Make
downloads return an actual file. A button must perform its stated, authorized
action or explain why that action is unavailable. Show a local preview and
test the full workflow on desktop, mobile, and with a keyboard.
## Two practical ways to collaborate on one Site
Start with the existing owner, approved source material, and tools the team
can actually use. Keep contributors' work separate until it is reviewed.
### Pattern 1: One human owner, separately approved handoffs
Name one human integration owner. Others can draft copy, check sources, or
review navigation and accessibility in distinct files, sections, or handoffs.
The owner resolves conflicting recommendations, combines approved changes, and
checks the result.
This works without simultaneous editing. A reviewer can supply approved copy,
screenshots, or feedback without becoming an editor or accessing unrelated
sources. Reading a draft, editing a shared Site, deploying it, and changing its
audience remain separate actions with separate approval requirements.
### Pattern 2: Isolated Git branches in an approved shared repository
If an approved shared repository is available, assign separate Git branches
and exclusive file ownership. Review each change against the same source
revision and acceptance checks. One human integration owner still decides
what to combine.
GitHub is an optional review service, not a requirement for building a Site.
Verify the account, repository, access, branch permissions, and workspace
policy before relying on it. A local branch is not pushed, reviewed, merged,
deployed, or shared simply because it exists. Pushing, opening a pull request,
merging, publishing, deploying, and changing access each need explicit human
approval for the intended action.
### What same-workspace access actually means
Verify the actual Site's sharing controls and the named person's role before
promising access. Viewer access is not editor access; an editor role does not
guarantee simultaneous or conflict-free editing. Neither grants permission to
publish, widen access, or change another person's work. If support is unclear,
use the single-owner handoff pattern.
For a bounded handoff, see [team collaboration without losing ownership](/guide/team-operating-systems),
the [task handoff template](/templates#task-handoff), and the
[human approval matrix](/templates#approval-matrix). Start the practical
exercise with the [Sites collaboration prompt](/prompts#site-collaboration).
## Copyable implementation
Choose a starting prompt, fill in your job and approved sources, and copy it
into your task. The prompts cover slide apps, dashboards, close reviews, and
forecast reviews. Keep the controls and review steps that fit the chosen format.
### Start with a format
- [HTML slides](/sites#html-slides): Tell a story with editable slides,
speaker notes, source references, and presentation mode.
- [Interactive dashboard](/sites#dashboard): Explore metrics through
Overview / Detail / Sources tabs. Add Trends only when the sources contain
history, and use filters only for available dimensions. Apply each filter
to the affected charts, tables, and exports.
- [Adapt the editable slide Site](/sites#html-site): Start with an independent
copy of the slide app. Keep the editor and slides together, then adapt them
to your work.
### Start with a Finance workflow
- [Monthly close review](/sites#monthly-close): Compare actuals with plan,
explain supported variances, and track open questions and action owners.
- [Forecast brief](/sites#forecast-brief): Show what changed from the prior
forecast, compare scenarios, and identify decisions. Keep assumptions and
exploratory scenarios distinct from the approved forecast.
Use the full prompts in the [Sites section](/sites) rather than maintaining
separate copies. Tailor the tabs and controls to the job; a useful reference
provides a starting layout, not someone else's content or source data.
## Example
A team uses the monthly close prompt with its approved actuals and plan files.
The header shows the period and currency. Summary leads with the results;
Variances explains the supported changes; Actions tracks unresolved questions
and owners. Changing a department filter updates the charts and table
together. The mascot links answers to the underlying source and flags an
unexplained variance instead of guessing.
The spreadsheet remains the source of truth. The Site makes the review easier
to navigate and repeat. The owner checks the source reconciliation and local
preview before approving any publication or access change.
## Approval boundary
Building locally is not the same as deployment. A deployed Site is not
automatically public. A visible draft is not approval to send a message, change
data, update a shared artifact, or give someone new access.
ChatGPT Work may prepare the Site, check its routes, and show a local review when the
user requests that work. Ask before publishing, deploying, changing access,
connecting live systems, or writing to a production source. Report which checks
passed, failed, or were not run. Call the requested work complete only when
the result and checks support that claim.
## Validation
Test the real surface rather than assuming the source looks right:
- The first page explains the job and offers a useful starting point.
- Tabs, toolbar controls, filters, and links do what their labels promise.
- The mascot cites supporting content and identifies unsupported questions.
- Each displayed download returns the actual described file.
- Sources, owners, dates, and review state are visible where needed.
- Contributors have distinct ownership and one human integration owner.
- Claimed editor, repository, and collaboration capabilities were verified.
- The experience works on small screens and with a keyboard.
- Missing data and unavailable services fail clearly.
- Local, hosted, restricted, and published states stay distinct.
## Failure modes
Common failures are copying a reference without adapting it to the job, adding
decorative controls, losing the source of a number, inventing an explanation,
hiding the decision owner, and mistaking a local preview for publication.
Start with the actual workflow. Build the smallest useful surface. Make every
claim, button, source, and download real.
---
# Implementation templates
---
## Tell ChatGPT how you like to work
_beginner | Give ChatGPT Work your preferred voice, useful background, and the decisions you want to keep._
# ChatGPT Work instructions
Use this when you are tired of re-explaining how you write, which information
to trust, or when you want ChatGPT to stop and ask before acting.
## How I work
- Start with the answer, blocker, or recommendation.
- Use plain language and the least formal style appropriate to the audience.
- Separate facts, assumptions, recommendations, owners, dates, and evidence gaps.
- Read the current source before making a mutable factual claim.
- Preserve the difference between a draft, a validated artifact, and a published result.
## How to write in my voice
- Match my wording and corrections in the active conversation first.
- Keep the main point, the minimum reasoning needed to make it credible, and the ask.
- Remove memo framing, repeated setup, generic polish, and stacked caveats.
- Draft sensitive or public communication before sending it.
- Never invent numbers, quotes, approvals, or currentness.
## Authority
- Reading, analysis, and drafting do not authorize sending, publishing, deploying, changing access, spending, or deleting.
- Urgency does not expand permission.
## Where more specific rules belong
- Put shared execution defaults in the supported global instruction surface.
- Put project sources, workflows, and validation in project instructions, or a project folder’s `AGENTS.md` where supported.
- Put repeatable procedures in Skills or runbooks.
- Use current source evidence to prove the result.
---
## Give ChatGPT Work the same ground rules across projects
_advanced | Set the instructions and safety rules that ChatGPT Work should remember when working across your projects._
# Global working instructions
Use these instructions for shared working rules. Keep personal voice preferences in ChatGPT Work instructions. Keep project-specific sources, routing, and workflows in the supported project instruction surface or a project folder’s `AGENTS.md` where available.
Confirm the supported global instruction location before saving this file. Use a global `AGENTS.md` or temporary `AGENTS.override.md` only when the environment supports that discovery mechanism. Review the proposed instructions before installing them.
## Operating stance
- Start with the outcome, blocker, or recommendation.
- Before acting, decide whether the work is a quick check, a sequential workflow, or safely parallelizable.
- Read the real source before making a mutable factual claim.
- Separate facts, assumptions, recommendations, owners, dates, and evidence gaps.
- Prefer existing workflows, templates, and validators over creating parallel systems.
- Preserve unrelated work and ask before destructive actions.
## Choose the work mode
- **Code or artifact work:** inspect the repository, reuse existing scripts and contracts, make the smallest safe edit, and validate the rendered result.
- **Analysis:** identify the source of truth, definition, grain, date window, units, inclusions, exclusions, and control tie-out.
- **Live preparation:** lead with sayable bullets, decisions, and where the audience may need to intervene.
- **Docs, slides, and messages:** reread the current artifact or conversation before citing it. Draft sensitive or public communication before sending.
- **Product or agent work:** default to a read-only review or support package unless deployment or live mutation is explicitly requested.
## Source, memory, and proof
- Treat screenshots, memory, and prior conversation as routing context unless the task establishes them as authoritative.
- Reread the canonical live file, application, record, or source before making a currentness or readiness claim.
- Name the proof surface and any coverage gap.
- Global instructions define universal behavior. Project `AGENTS.md` files define local policy. Skills and runbooks define repeatable procedures. Current evidence proves the result.
## Task orchestration
- Do not create process overhead for a quick question or one-shot edit.
- For material work, establish the objective, acceptance checks, dependencies, and approval boundary first.
- Parallelize only independent work with locked inputs and separate file ownership.
- Keep shared schemas, renderers, configuration, integration, deployment, and final readiness under one owner.
- Leave a checkpoint when the work changes lanes or cannot be completed in the current task.
## Mutation and outbound boundaries
- Reading, analysis, and local drafting are allowed when relevant to the request.
- Local project edits are allowed only when the user asks to build or change something.
- Sending, posting, publishing, deploying, changing access, deleting data, and modifying live systems require explicit authorization.
- Urgency does not expand permission.
## Validation and lifecycle
- Test the exact artifact or workflow changed.
- Check the rendered or live surface when behavior or appearance matters.
- Report what was checked, what passed, what remains unverified, and the next approval boundary.
- Keep `draft`, `validated`, `release candidate`, `deployed`, and `published` separate.
- Treat currentness as a separate dimension. A validated artifact can still be stale.
## Communication
- Use plain language and the least formal style appropriate to the audience.
- Lead with the answer, then add only the evidence needed to make it credible.
- Match the user’s active wording and corrections before applying a generic style.
- Do not invent numbers, quotes, approvals, or currentness.
---
## Tell ChatGPT Work how this project works
_intermediate | Explain one project's trusted sources, workflow, quality checks, and decisions that still need your approval._
# Project instructions
These instructions refine the shared working rules for one project. They should not repeat universal voice preferences or turn a detailed procedure into permanent context. Put repeatable procedures in Skills or runbooks.
Use the supported project instruction surface. In file-backed projects that support `AGENTS.md`, place broad guidance at the repository root and add nested files only where different rules are needed. Verify discovery order and precedence in the current environment. Use `AGENTS.override.md` only where supported and when you mean to replace the regular file for that directory.
## Purpose and non-goals
Describe the durable outcome this project owns in two or three sentences.
State what the project does not own so adjacent work routes correctly.
## Source hierarchy
1. Name the canonical live system or artifact.
2. Name the approved local mirror or export.
3. Name routing context that may help discovery but cannot prove current state.
For every mutable source, name its owner and currentness rule.
## Context routing
- Route each major request type to the correct workflow, owner, or system.
- Name any upstream handoff required before this project can use another project’s output.
- Block unsupported, stale, missing, or mismatched handoffs instead of silently repairing them.
## Required workflow
1. Confirm the objective and acceptance criteria.
2. Read the canonical sources in the required order.
3. Reuse the project’s existing scripts, schemas, and templates.
4. Make the smallest reviewable change.
5. Run the named validation checks.
6. Report the exact lifecycle state and remaining approval boundary.
## Project-specific guardrails
- Define metric formulas, grain, time windows, units, and exclusions when numbers matter.
- Keep local preview, hosted review, production, and publication separate.
- Route cross-project corrections to the system that owns the value.
- Do not edit live systems, send messages, or change access without explicit authorization.
## Validation and definition of done
List the evidence paths, tests, visual checks, reviewers, and promotion gates required before the work can advance.
## Handoff and recovery
For material work, record the verified current state, exact artifact revision, decisions, blockers, residual risks, next owner, and restart step. Build the handoff from current files and proof, not conversation memory.
---
## Keep the project and its sources in one place
_beginner | Record what the work is for, who owns it, which information to trust, and what must stay under human control._
# Project charter
## Objective
State the durable business outcome, the primary audience, and what decision or workflow the project supports.
## Owners
| Role | Owner | Decision rights |
| --- | --- | --- |
| Business owner | `` | Defines success and approves material changes |
| Source owner | `` | Owns definitions and source quality |
| Builder | `` | Implements and validates |
| Reviewer | `` | Confirms usability and controls |
## Scope
- In scope:
- Out of scope:
- Approval required for:
# Source map
| Source | Purpose | Owner | Grain | Currentness check | Authority |
| --- | --- | --- | --- | --- | --- |
| `` | `` | `` | `` | `` | Canonical |
| `` | `` | `` | `` | `` | Approved mirror |
| `` | `` | `` | N/A | `` | Define for this task |
Assign authority for the fact you need. A message can be the original source
of a request or decision; it does not replace a maintained tracker for current
project status. Use only the messages and notes approved for this task.
## Missing-data behavior
Use `pending`, blank, `n/a`, or an explicit coverage note. Never silently borrow a nearby value or older case.
---
## Track active work and who owns it
_intermediate | See what is in progress, avoid duplicate work, and make the next step and owner clear._
# Task registry
Use one record per durable task.
| Field | Value |
| --- | --- |
| Task title | `; — ` |
| Canonical task ID or link | `` |
| Project | `` |
| Objective | `` |
| Owner | `` |
| State | `active / waiting / review / blocked / paused / complete / archived` |
| Last verified | `` |
| Next action | `` |
| Approval boundary | `` |
| Successor or handoff | `` |
## Registry rules
- Keep one canonical implementation task per project objective.
- Treat similarly worded tasks as possible duplicates until ownership and artifacts are compared.
- Do not rename, archive, move, or message an existing task merely because a scan found it.
- A draft awaiting human review stays in `review`; it is not complete or idle work.
- Use `waiting` for a named dependency, `blocked` for an issue requiring intervention, and `paused` for work deliberately stopped.
- If continuity is ambiguous, stop and record the gap instead of creating a new task.
---
## Pick the work back up without starting over
_beginner | Save the current result, trusted context, open questions, and next step in one short checkpoint._
# Restart card
## Goal
``
## Verified current state
- Completed:
- Current artifact and version:
- Evidence checked:
- Last successful validation:
## Locked decisions
- Decision:
- Constraint:
- Non-goal:
## Open work
1. ``
2. ``
3. ``
## Risks and unknowns
- `` — proof needed:
- `` — mitigation:
## Restart instructions
1. Re-read this card and the named current artifact.
2. Verify the artifact still matches the recorded version or checksum.
3. Confirm no other owner has taken the pen.
4. Execute only the first safe next action.
5. Refresh this card after three material milestones or a lane change.
## Approval boundary
No send, publish, deployment, destructive change, or live-system mutation is authorized by this card alone.
---
## Hand work to the next person or task
_intermediate | Explain what is finished, what still needs review, and who should take the next step._
# Task handoff
## Delivery mode
`continue / pause / new task`
## Goal
``
## Verified state
- Current artifact:
- Lifecycle state:
- Currentness:
- Tests and evidence:
- Owner with the pen:
## Locked decisions and constraints
- Facts:
- Decisions:
- Non-goals:
- Authorization boundary:
## Remaining work
1. ``
2. ``
3. ``
## Acceptance gates
- Functional:
- Content/data:
- Visual or usability:
- Approval:
- Promotion:
## Residual risks
- Unknown:
- Blocker:
- Stale or partial surface:
For `new task`, append a suggested title and a self-contained opening prompt. Do not create the new task unless the user explicitly requests it.
---
## Write down a workflow you can repeat
_intermediate | Capture the real job, trusted sources, repeated corrections, review steps, and expected result._
# Workflow specification
Use this after trying the real job. Keep the steps and corrections that remain
useful on a fresh example; leave out the details that apply only this time.
## Trigger
What event or request starts the workflow? State any time window and required inputs.
## Outcome
Describe the finished business result and the decision it supports.
## Inputs and source order
| Input | Required | Authority | Failure behavior |
| --- | --- | --- | --- |
| `` | Yes/No | Canonical/Mirror/Routing | Block/Partial/Skip |
## Steps
1. Verify source access and currentness.
2. Normalize inputs without changing their meaning.
3. Produce the artifact or analysis.
4. Validate against named controls.
5. Prepare the result for review.
## Output contract
- Artifact:
- Required sections or fields:
- Evidence receipt:
- Lifecycle state on success:
- No-change output:
## Permissions
List read, local-write, live-edit, send, publish, and destructive permissions separately.
## Exceptions
Define missing data, conflicting owners, duplicate work, stale sources, delivery uncertainty, and partial coverage.
---
## Turn repeated corrections into a Skill
_advanced | Draft reusable judgment while the real example is fresh, then test it on new examples while keeping important decisions with a person._
# Skill specification
Start this draft after you have worked through a real example and corrected
the result. Capture what matters while the original sources, example, and
feedback are still available in context. Then test the draft on fresh
examples before treating the Skill as reliable. One good result is not
validation.
## Name and description
Name the job in language a user would naturally say. The description should state when the Skill applies and when it does not.
## Trigger examples
- Positive:
- Positive:
- Negative:
## What the first example taught
- Trusted source and audience:
- Real example reviewed:
- Corrections that should apply again:
- One-time details to leave out:
- Decisions that stay with a person:
## Preconditions
- Required source access:
- Required project context:
- Required user decision:
## Procedure
1. Read the project instructions and canonical sources.
2. Establish input completeness and ownership.
3. Execute the smallest workflow that satisfies the request.
4. Run deterministic validation.
5. Return the result, evidence, gaps, and next approval boundary.
## Output schema
- Outcome:
- Facts:
- Assumptions:
- Evidence:
- Residual risks:
- Next action:
## Safety
Keep reads, local drafting, live edits, outbound messages, publication, deployment, access changes, and deletion as separate permission states.
## Evaluation cases
Include a fresh real example, a missing-source case, a duplicate-work case,
an approval case, and a no-change case. Record what changed after each test.
Do not call the Skill reliable until it works beyond the example that taught
the first draft.
---
## Automate one proven step safely
_advanced | Let ChatGPT Work prepare a predictable next step while keeping sending, sharing, and other important actions under your control._
# Automation contract
Use this only after the workflow works with fresh examples. Start small, make
the action reviewable, and state exactly when ChatGPT Work needs to stop and ask.
## Purpose and cadence
- Business outcome:
- Trigger or schedule:
- Time zone:
- Allowed execution window:
- Stop condition:
## Controller
- Canonical project:
- Canonical controller task:
- State location:
- Maximum concurrent work:
- Lease or duplicate-prevention rule:
## Allowed actions
- Read:
- Write internally:
- Draft:
- Continue existing work:
## Prohibited without approval
- Send or post.
- Publish or deploy.
- Change access.
- Delete or overwrite source data.
- Create multiple parallel tasks for the same ask.
## Decision sequence
1. Verify the time gate and controller identity.
2. Read a bounded source window.
3. Check ownership and duplicates.
4. Select at most one safe intervention.
5. Record evidence and lifecycle state.
6. Return `no material change` when nothing qualifies.
## Failure behavior
Fail closed on ambiguous ownership, partial source coverage, delivery uncertainty, expired authorization, or unavailable validation.
---
## Keep the important decisions with a human
_advanced | Make it clear what ChatGPT Work can prepare and what still needs your approval before anyone acts._
# Approval and mutation matrix
| Action | Default | Evidence required | Approver |
| --- | --- | --- | --- |
| Read canonical sources | Allowed when relevant | Access and source identity | Project policy |
| Analyze and summarize | Allowed | Source citations and currentness | Project policy |
| Create local draft | Allowed for requested work | Named local artifact | Requester |
| Edit local project files | Requires build/change request | Diff and validation | Requester |
| Edit live document | Explicit approval | Exact target and revision | Artifact owner |
| Send message or email | Explicit approval | Final recipient, subject, body | Sender |
| Deploy or publish | Explicit approval | Validated exact version | Release owner |
| Change access | Explicit approval | Exact people, roles, duration | Resource owner |
| Delete or overwrite | Explicit approval | Exact target and recovery plan | Resource owner |
## Rule
Permission is scoped to the named action, target, and version. Approval to draft is not approval to send. Approval to deploy one version is not continuing authorization. Urgency, priority, and confidence do not expand the envelope.
---
## Improve what you keep having to correct
_intermediate | Notice what repeats, keep the useful lesson, and make one practical improvement at a time._
# Reflect and refine
## Review window
- Period:
- Completed or explicitly paused work reviewed:
- Evidence cutoff:
## What worked
| Pattern | Evidence | Reuse opportunity |
| --- | --- | --- |
| `` | `` | `` |
## Friction
| Symptom | Root cause | Cost | Recurrence |
| --- | --- | --- | --- |
| `` | `` | `