Feeding it the right context: files, screenshots, web search, connected apps

"Context" is any information that would change the result. The rule is: give it only relevant sources, and say clearly what to pull from each one. Here are the main ways to feed it context:

Use the latest project plan in Drive and relevant decisions and updates from
the project's Slack channel to prepare a status update.

Connected data sources need the matching plugin installed, and whether you can use them depends on your plan and workspace settings. To point at a specific plugin, type @ in the input box and pick it. One more distinction worth keeping straight: preferences that apply every time (default tone, habits) belong in the custom instructions under "Settings > Personalization"; details that only matter for this one task belong in that task's prompt.

Don't rewrite when the result's off: follow-up messages, plus steer vs. queue

Your first prompt doesn't need to nail it in one shot. Look at the result, say exactly what to change, and you can add sources, correct direction, swap versions, or adjust detail level — without starting over.

Make the opening more direct, keep the evidence, and move the recommendation
above the background section.

Codex adds another layer: while it's running, you can send another message, and where it lands depends on how you send it.

In the desktop app, the default behavior is set under "Settings > General > Follow-up behavior"; queued messages show above the input box, where you can edit, reorder, send, or delete them. In Codex CLI, while it's running, Enter steers the current turn and Tab queues for the next one. Worth noting: the desktop app also supports voice dictation — hold Ctrl + M to talk, and what you say gets transcribed into the input box for you to review and edit before sending.

One full example: mapping the four elements onto a real prompt

The four elements aren't rigid boxes. Below is a real, complete prompt with four colors marking which sentences are goal, context, output, and boundaries — one look and you'll see how they weave into a single passage.

Breakdown: [Goal] Prepare a one-page project status update for Monday's leadership meeting. [Context] Use the latest project plan in Drive plus relevant decisions and updates from the project's Slack channel. [Output] Lead with the decisions leadership needs to make and the next steps, then summarize progress, risks, owners, and due dates. [Boundaries] Keep approved dates and budget figures unchanged; flag any conflicting or missing information; don't send or publish anything. [Boundaries · final check] Before finishing, check every next step has an owner and a due date.

It covers goal, context, output, and boundaries, with a final check tacked on at the end — but it doesn't spell out every single step. That's what "assemble as needed" looks like for the four elements.

Everyday questions go to Chat, finished deliverables go to Work

Chat is for asking questions, brainstorming, drafting, and everyday decisions — start from the result you want, then add detail as needed. Work is for tasks that pull from multiple sources or tools, run multiple steps, or produce a larger finished file. Below are official examples, each ready to copy and adapt.

Chat: four examples for everyday questions

Explain how compound interest works for someone who has never invested.
Use one concrete example and define any financial terms you introduce.

Draft a friendly email declining this invitation because I will be traveling.
Keep it under 120 words and leave the door open for a future event.

Compare these two phone plans for one person who travels internationally twice
a year. Show the important differences in a table, then recommend one and
explain the tradeoff.

Plan five weekday dinners that take less than 30 minutes. Avoid peanuts, reuse
ingredients across meals, and finish with one consolidated shopping list.

Work: three examples for finished deliverables

Use the attached quarterly reports to create a leadership brief and a six-slide
presentation.

The audience is the executive team. Lead with the three decisions they need to
make, distinguish reported facts from your analysis, cite each number to its
source file, and check that the brief and slides agree before you finish.

Research three customer-support platforms for a 50-person company. Compare
pricing, security, integrations, and migration effort using current sources.
Deliver a recommendation memo with links, assumptions, and the questions we
should answer before signing a contract.

Create a launch plan for the attached product brief. Include the timeline,
owners, dependencies, risks, announcement draft, customer FAQ, and a checklist
for launch day. Flag any missing decisions before producing the final files.

Tips for using Work: start with a small result you can actually review, keep the source range tight and dates specific, and separate the must-do work from optional polish. When the process itself matters, have it draft a plan first, and require your approval before it sends, publishes, or changes information others depend on. Once a workflow like this is working, reuse it going forward — and for repetitive work, you can set it to run automatically on a schedule right from that task.

Codex's three fundamentals: understanding code, fixing bugs, writing tests

Use Codex whenever you want ChatGPT working with code, a codebase, or developer tools. A good Codex prompt names the behavior you want, points at the relevant code or repro steps, states the constraints that matter, and says how to verify the result. All three below are ready to copy directly.

Two bits of background first: the IDE extension automatically treats your open files as context; in the CLI you need to name paths explicitly, or use @ autocomplete or /mention to attach files. Also, when Codex runs commands locally it's confined to a sandbox with restricted file and network access — anything that would cross that boundary (like reaching the internet, or editing files outside the sandbox) has to clear your approval policy first.

Understanding a codebase

Use this when you're picking up an unfamiliar service, or want to untangle a protocol or request flow.

Explain how the request flows through the selected code.
Include:
- a short summary of the responsibilities of each module involved
- what data is validated and where
- one or two "gotchas" to watch for when changing this

(验证追问) Summarize the request flow as a numbered list of steps. Then list the files involved.

codex

I need to understand the protocol used by this service. Read @foo.ts @schema.ts and explain the schema and request/response flow. Focus on required vs optional fields and backward compatibility rules.

Fixing a bug

Use this when you have reproducible bad behavior in hand. A repro recipe plus the files you suspect is far more useful than a high-level description.

codex

Bug: Clicking "Save" on the settings screen sometimes shows "Saved" but doesn't persist the change.
Repro:
1) Start the app: npm run dev
2) Go to /settings
3) Toggle "Enable alerts"
4) Click Save
5) Refresh the page: the toggle resets
Constraints:
- Do not change the API shape.
- Keep the fix minimal and add a regression test if feasible.
Start by reproducing the bug locally, then propose a patch and run checks.

(验证追问) After the fix, run lint + the smallest relevant test suite. Report the commands and results.

Find the bug causing "Saved" to show without persisting changes. After proposing the fix, tell me how to verify it in the UI.

Writing unit tests

Use this when you want to scope precisely what gets tested. In the IDE, select the function's code and ask; in the CLI, name the function directly.

(IDE，选中函数代码后) Write a unit test for this function. Follow conventions used in other tests.

(CLI，直接点名函数) Add a test for the invert_list function in @transform.ts. Cover the happy path plus edge cases.

Codex's three advanced workflows: screenshot to prototype, live-preview iteration, delegating to the cloud

Three more advanced workflows: turning a design screenshot, mockup, or UI reference directly into a working prototype; iterating on code while watching it live in the browser; and taking a plan you worked out locally for a time-consuming refactor and handing the execution off to the cloud.

Screenshot to prototype

Use this when you want to turn a design mockup, screenshot, or UI reference into a working prototype. The image gives the visual requirements — you still need to spell out implementation constraints like framework, routing, and component style in words, and describe any behavior the image can't show (hover states, validation rules, keyboard interactions).

codex

(拖入截图后) Create a new dashboard based on this image.
Constraints:
- Use react, vite, and tailwind. Write the code in typescript.
- Match spacing, typography, and layout as closely as possible.
Outputs:
- A new route/page that renders the UI
- Any small components needed
- README.md with instructions to run it locally

(验证追问) Start the dev server and tell me the local URL/route to view the prototype.

(IDE版，贴截图) Create a new settings page. Use the attached screenshot as the target UI.
Follow design and visual patterns from other files in this project.

UI iteration with live preview

Use this for the "design → tweak → refresh → tweak again" style of quick iteration. Run the dev server on one side, and converge over a few rounds using small, specific instructions.

codex
npm run dev

第一轮：Propose 2-3 styling improvements for the landing page.

第二轮（选定方向后细化到具体元素）：Go with option 2.
Change only the header:
- make the typography more editorial
- increase whitespace
- ensure it still looks good on mobile

第三轮（继续收敛）：Next iteration: reduce visual noise.
Keep the layout, but simplify colors and remove any redundant borders.

Check the browser after each round; commit if you like it, revert if you don't. If you've manually edited or reverted something yourself, tell Codex — otherwise the next round might overwrite your change.

Delegating a refactor to the cloud

Use this when you want to plan locally with local context first, then hand the time-consuming implementation off to run in parallel in the cloud. The key part: a plan worked out locally can migrate to the cloud with its full context intact.

本地规划：
$plan
We need to refactor the auth subsystem to:
- split responsibilities (token parsing vs session loading vs permissions)
- reduce circular imports
- improve testability
Constraints:
- No user-visible behavior changes
- Keep public APIs stable
- Include a step-by-step migration plan

修订计划：
Revise the plan to:
- specify exactly which files move in each milestone
- include a rollback strategy

切到云端环境后：
Implement Milestone 1 from the plan.

Tasks delegated to the cloud run in an isolated environment, and the agent stage has no network access by default unless you've enabled it for that environment. Once Milestone 1 works, move on to the next milestones one at a time.

Codex can review your code too: one local command, or @-mention it on GitHub

When you want a second pair of eyes before a commit or a PR, there are two routes: a local slash command, or @-mentioning it in a GitHub comment thread. Both support targeted focus instructions — say, only looking at security issues.

/review

(定向聚焦) /review Focus on edge cases and security issues

@codex review

(定向聚焦) @codex review for security vulnerabilities and security concerns

After the local review, once you've addressed the feedback, run /review again to confirm everything's resolved.

One more: updating docs

When you need one accurate, clear documentation change, pin down the files to edit, state the scope, and ask it to verify.

Update the "advanced features" documentation to provide authentication troubleshooting guidance. Verify that all links are valid.

How to start: pick the simplest workflow first (like understanding a codebase), get it working, then reuse that pattern for the rest.

OpenAI's answer is four things: goal (what result you want), context (what material to give it), output (what format you want), boundaries (what it absolutely can't touch). Use what you need — you don't have to fill in every one. Of the four, "boundaries" is the one most often left out, yet it's the one that does the most to prevent wandering off track and unwanted actions. Same task, half-said versus fully spelled out — here's the difference:

Let's walk through exactly how these four blocks weave into a sentence and produce a result, using one of XiaoHu's own tasks.

XiaoHu has notes from a meeting and wants them turned into an update for the team to read. What he needs to do is assemble the four pieces of information above into one complete instruction and feed it to the AI.

The same principles land in three places: everyday questions go to Chat, finished deliverables go to Work, and anything touching code goes to Codex. If a result isn't right, you don't have to rewrite it — just say what to change. And while Codex is running, you can still send a follow-up: steer redirects it on the spot (cuts into the current turn), or queue holds it for the next turn.

Codex specifically comes with 9 command-level workflows: understanding code, fixing bugs, writing tests, turning a screenshot into a prototype, iterating on UI with live preview, delegating refactors to the cloud, reviewing code, and updating docs — each one paired in the article with a copy-ready prompt.

The numbers 4, 3, and 9 all come from OpenAI's official documentation; the English prompt examples in the article are preserved exactly as written, with no third-party benchmarking involved.