Codex Intro Workshop Workbook

A 30-minute guide for business and operations teams.

Core message ChatGPT is useful for thinking through work. Codex is useful when you need work finished.
Main shift Stop writing step-by-step instructions for the thing you assume should be built. Explain the business result, context, risks, and approval boundaries.
Practice focus Outcome-first requests, access, feedback, unclear requests, blockers, and goals.

Concept Checklist

By the end of the workshop, you should understand these ideas and be able to use the prompt patterns in this workbook.

1. Advice vs Finished Work

Codex is different because you can ask it to finish the job, not just explain the situation.

ChatGPT-style request Codex-style request
Here is Livatro 7001 sales data. Why did sales drop?

This may explain the data you gave it, but you still need to decide what else to check, update the spreadsheet, and prepare the team message.

Finish the Livatro 7001 sales-drop analysis.
Figure out what needs checking, gather what you can,
put the result in a spreadsheet, and prepare the team message.
Ask me only if you hit a real blocker or need approval.

This gives Codex the result to deliver and tells it when to come back to you.

2. Why Codex Can Finish Work

The difference is not simply that Codex has tools. ChatGPT can also read emails, browse, and connect to data. The important change is that Codex can take action in the places where work happens.

Plugins and internal tools Computer use
  • Feishu Mail: prepare replies, review threads, and send after approval.
  • Excel: build, clean, and update analysis workbooks.
  • Snowflake/internal data tools: check the real business data behind a question.
  • Figma: create diagrams and workflow visuals.
  • Open CyberFlo and try a workflow directly.
  • Read Feishu or WeChat chats when no direct plugin exists.
  • Use vendor portals, internal web apps, or websites with no plugin.
  • Open PDFs, screenshots, spreadsheets, and downloaded files.
  • Click, type, inspect what is visible, and stop before approval-sensitive actions.
Computer-use example: The video below shows Codex using the computer directly when the work lives in an app or page rather than a dedicated plugin.
Plugin example: The video below shows Codex doing real work through a plugin. If the workbook is printed, use the local video file listed below.

3. Ask For The Business Result

The main working habit is to explain the actual business result before naming the tool you think Codex should build.

Bad Better Best
Design a dashboard with X filters at the top,
Y charts on the right side,
and a Z summary section at the bottom.

This over-controls the layout before Codex understands the problem.

I need a faster way to answer questions like X, Y, and Z.
Right now it takes too long to find the right numbers,
check whether the issue is real, and prepare a response.

Please design the simplest useful tool or workflow for this.

This explains the pain and gives Codex room to choose the solution.

I need a tool, possibly a dashboard, that helps me answer questions like X, Y, and Z quickly and accurately during ecommerce performance reviews.

The main person asking is usually Carson. He tends to challenge the worst-performing indicators, even when overall performance is good.

This tool should help me quickly find weak spots, check whether they are real problems or just noise, and prepare a clear response with the evidence behind it.

Avoid a heavy dashboard if a simpler guided analysis, Excel workflow, or reusable report would get us to the answer faster.

This explains the real job, user, pressure, and success criteria.

Common blocker: Some people feel they need a perfect prompt before starting. Others write a long prompt with exact steps. Codex follows those steps, hits a roadblock, and then feels rigid. Often, Codex only failed because it was trying to do the job your way.

The better habit is to give Codex the goal, context, risks, and approval boundaries. Let it decide the path.

4. Start Small, Then Give Feedback

The backpack example shows why feedback beats trying to plan everything upfront.

Waterfall development compared with agile development using a backpack example.
Waterfall tries to plan and build everything before feedback. Agile starts small, collects feedback, and improves through iteration.
All-upfront planning Codex working style
  1. Plan everything.
  2. Build everything.
  3. Find problems too late.
  1. Ask for the first useful result.
  2. Review the result and the decision behind it.
  3. Push Codex to revise.

Good feedback criticizes both the result and the decision behind it. Do not just hand Codex the right answer with no context. A person learns better when you explain why something was wrong and guide them toward the right answer. Codex works the same way.

Weak feedback Better feedback
You should do X.
This result is subpar because you chose Y.
If we do Y, we will have this problem.
Please revise toward [desired outcome].
If you think your choice is still right, explain why.
Traits of a good manager: Do not clean up after Codex. Call out the issue and make Codex fix it.

5. If You Are Unsure, Make Codex Ask

Sometimes you know the pain, but not the solution. Do not force a fake clear request.

I have a problem/painpoint, but I am not sure what solution we need.
[Describe problem or painpoint]
Ask up to 5 most important questions.
Only ask questions that would change the final result.
Then recommend what we should do.

6. Do Not Worry About Setup

Setup means the prompts, plugins, internal tools, skills, and access Codex needs. Business users do not need to manage this directly.

Focus on the result. If Codex needs something, it will usually say so. If someone else’s Codex can do something yours cannot, ask the CyberFlo team. It is often a simple fix: add a plugin, connect an internal tool, enable computer use, or pass along an instruction.

7. When Codex Falls Short

Do not take the work back too early. Find what is blocking the work and push it forward.

This is incomplete.
Do not make me finish it manually.
Tell me what is missing: goal, information, access, permission, or checking.
Then keep going as far as you safely can.

Being a good Codex user is similar to being a good manager: give useful feedback, remove blockers, and push the work back to Codex.

8. Common Friction And Remedies

These are normal early-stage issues. The goal is not to avoid all friction; it is to know how to respond so Codex can keep moving toward the result.

Challenge What it looks like Remedy
Too slow Codex takes a while, especially when using the computer or checking several sources. Avoid tiny tasks where you need to interject every step. Assign a sizeable deliverable, let it work, then review the result. For independent work, run multiple Codex threads in parallel.
Data fetching errors A query fails, a source is missing, data access is unclear, or the correction loop gets long. Ask what failed, what source it tried, and the smallest thing needed to continue. Also treat these errors as feedback for the data team. Early errors help improve the agent, data access, and source definitions.
Results are inconsistent The same type of request produces different formats, checks, or decision quality. When you find a good process, ask Codex to turn it into a skill. If the process should happen repeatedly, automate it on a regular interval.
Tool use is unstable A plugin fails, a page changes, a login expires, or Codex uses the wrong path for a task. Tell Codex which path to remember for future work. Example: “For reading messages on Feishu, please always use computer use to access the app directly.”
Looks confident but missed something The result sounds polished, but it skipped a source, assumption, edge case, or required check. Ask for evidence before relying on it: “What did you verify, what did you assume, and what remains unchecked?” Then have Codex fill the gaps or clearly mark the remaining uncertainty.

9. Bonus: /goal

Normal Codex can already finish many basic jobs. Use /goal for longer jobs that may need follow-up.

Basic jobs

Read this Feishu Mail thread, write the reply, ask before sending, then send it after approval.
Finish this Snowflake-backed analysis, put it in Excel, and prepare a Feishu message to Y.
Open this CyberFlo page, try the workflow, and prepare the improvement brief.

Ecommerce example

/goal Resolve this customer's replacement issue.
Use Feishu Mail and CyberFlo if needed.
Write the reply draft in Feishu Mail.
Ask before sending.
After I approve, send it.
If the customer replies, continue until resolved or blocked by my decision.

Handout Prompts

Ask for a result

I need to accomplish [result].
The problem is [pain].
Figure out the best way to help.
Ask me only if something important is missing.

Give better feedback

This result is subpar because [decision or assumption].
If we do it this way, [problem].
Please revise toward [desired outcome].
If you think your choice is right, explain why.

Make Codex fix it

This is wrong or messy.
Do not make me clean it up by hand.
Explain what went wrong if needed, then fix it.

Make Codex ask

I have a problem/painpoint, but I am not sure what solution we need.
[Describe problem or painpoint]
Ask up to 5 most important questions.
Only ask questions that would change the final result.
Then recommend what we should do.

After-Class Supplement

For a lighter follow-up guide, read How to give Codex a finish line. It summarizes how to frame normal Codex tasks as deliverable results.