zero2codex
OpenAI Codex workflow course

Course goal: ship your personal brand site

Build a personal brand site with Codex

Keep improving one project from an empty folder to a responsive one-page site with an introduction, projects, and contact details. Every lesson adds a visible result or a check toward that finish line.

Curriculum

Personal brand site build path

01

Start With Codex

Set up Codex and build the hero section of your personal brand site.

0/4
02

Prompt Like A Builder

Map the site, plan its sections, and turn rough ideas into clear changes.

0/3
Find the Files to ChangeAsk Codex to show which files control each part of the site before you edit anything.Plan Before CodingPlan the site's theme control before editing, including risks and browser checks.Define Done WhenDefine visible completion checks, then implement the site's light and dark themes.
8 minReady

Define Done When

Make completion measurable before work starts.

acceptance criteriaverification evidencefinal report

Watch, then try

06|依完成條件實作(CLI 版・32 秒)

真實 CLI 輸出檢視器與本機網站錄影,非 Codex 原生介面;繁中字幕、無旁白,等待區段已剪接。

zero2codex
MP4

Step-by-step

  1. 沿用前一課的 my-brand-site,或從下方練習檔取用本課 before 起點。
  2. 在專案目錄執行本片 CLI 指令;本課權限為 workspace-write。
  3. 核對實際輸出與結束碼,不把文字回報當成瀏覽器操作證據。
  4. 在真實瀏覽器按兩次,驗證配色與按鈕名稱恢復。
跟著本片操作:CLI 指令與練習檔(繁體中文)

這是本課的 CLI 替代實作路徑;下方概念課程仍保留其他介面的說明。先安裝並登入 Codex CLI,在 my-brand-site 資料夾內執行下列 macOS/Linux 指令。影片將真實 CLI JSON 事件排版成易讀畫面,下列指令使用一般 CLI 輸出;不是 Codex 原生介面,等待區段已剪接。

codex exec --ephemeral --ignore-user-config --sandbox workspace-write '只修改 index.html,依這份已核准的計畫新增深淺主題切換:1 CSS 變數定義兩個配色;2 原生 button 切換,名稱清楚顯示下一個動作『切換到深色主題』或『切換到淺色主題』;3 點兩次回原主題。保留 CTA、內容、手機版。不存 localStorage,以初始淺色為準。實際檢查程式;瀏覽器視覺驗證由錄製者做,勿聲稱已做。'

下載逐課練習檔與實際結果(ZIP)

15-minute lab

Hands-on lab

Implement the approved theme switch only after defining visible, checkable completion criteria. This closes the plan-to-proof loop from the previous lesson.

Before you start

  • Open the approved theme-switch plan from the previous task.
  • Preview index.html and confirm the Projects button still moves to the right section before editing.

Do it now

Good prompt

Codex, implement the approved accessible light/dark theme switch in index.html. Keep one file, add no packages, and preserve the existing Projects button. Done when: (1) the theme control has a clear accessible label, (2) switching twice visibly returns to the starting theme, (3) the Projects button works in both themes, (4) wide and narrow layouts have no horizontal overflow, and (5) you report the changed file plus the result of every check.

What success looks like

  • A clearly labeled control switches the page between light and dark themes.
  • The Projects button still works in both themes.
  • The page works at wide and narrow widths, and the final report lists each check separately.
Stuck? Try this
  • If Codex says “done” without evidence, paste the checklist again and ask for one result per condition.
  • If the original button breaks, ask Codex to reproduce that regression before making the smallest fix.

Plain-language explanation

“Done” should mean more than “Codex stopped editing.” A good done condition says what behavior changed and what evidence proves it.

Done-when criteria can include passing tests, a successful build, a screenshot, a browser check, or a clear explanation of remaining risk.

Why it matters

Completion criteria protect you from vague success. Codex can report exact evidence instead of asking you to trust that the change worked.

Common beginner mistake

The common mistake is accepting a confident final message without a command, output, or manual check you can verify.

Try this

Take a task and add two done-when bullets: one automated check and one human-readable behavior check.

Completion checklist

  • Your request includes at least two done conditions.
  • The final evidence can be checked without reading every edited line.

Sources

08

Finish And Deliver The Site

Polish independent tasks in parallel, then complete one final acceptance review.

0/3

Practice lab

Copyable Codex prompts

Plan before coding

Codex, inspect the relevant files first, then propose a plan. Do not edit until the plan names tests and verification steps.

Verification checklist

  • Relevant files are named before edits begin.
  • The plan includes tests and verification commands.

Verify a UI change

Codex, start the dev server, open the route in the browser, check desktop and mobile layouts, then report the exact evidence.

Verification checklist

  • Desktop and mobile states are checked in the browser.
  • The final note includes exact evidence.

Review focused risk

Codex, review the uncommitted diff. Focus on behavioral regressions, missing tests, and accessibility issues. Do not modify files.

Verification checklist

  • Findings lead with severity and file references.
  • Unchanged files are left untouched.
Every good Codex request says what to change, what to preserve, and how to prove it worked.

Reference

Codex concepts to keep nearby