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
00｜Install And Open CodexInstall the desktop app, sign in, open the site project folder, and send a safe first message.What Codex Is ForBuild the first version of your site with a name, introduction, projects, contact details, and one working button.Choose A Codex SurfaceEdit the site's Projects button locally, then verify its text and behavior in a browser.Your First Useful PromptTurn “add an About section” into a concrete request with content, constraints, and browser checks.
07

Build A Site QA Workflow

Create reusable checks for the site's content, links, and browser behavior.

0/3
Turn Site Checks Into A SkillPackage the personal site's pre-launch content, link, mobile, and accessibility checks into one reusable skill.Bring In Project Data SafelyDecide whether project cards need outside data, and use the smallest read-only connection only when it adds value.
11 minReady

Bring In Project Data Safely

Keep the site local by default and connect external project data only with a clear reason and boundary.

local contentread-only toolsminimal data scope

Plain-language explanation

Your Projects cards can stay as text in index.html. If you want live public repository details later, an MCP tool could read them, but that connection is optional.

Start local. Add a tool only when fresher project data clearly improves the site, and keep it read-only with a small response.

Why it matters

This keeps a simple portfolio from gaining unnecessary permissions or moving parts.

Common beginner mistake

Beginners sometimes connect an entire account when the site only needs a project name, URL, and short description.

Step-by-step

  1. Decide whether hand-written project cards are already enough.
  2. If not, list the exact public fields the site needs.
  3. Choose read-only access and exclude private repositories or account actions.
  4. Keep a local fallback if the external data is unavailable.

Good prompt

Codex, decide whether my-brand-site should keep its Projects cards local or read public repository metadata through MCP. If a tool helps, limit it to read-only project name, URL, description, and updated date. Explain the benefit, permission boundary, and local fallback.

Try this

List the smallest set of public fields one project card would need from an external source.

Completion checklist

  • The plan explains why local content is or is not enough.
  • Any proposed tool is read-only and limited to site fields.

Sources

Test Contact SafelyTest the Contact section with sample data and stop before anything is sent to a real service.
08

Finish And Deliver The Site

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

0/3
Complete The Site GoalTurn the finished personal site into one measurable goal with content, layout, interaction, and evidence checks.Polish Copy And Accessibility In ParallelUse isolated worktrees only when copy polish and accessibility review can avoid editing the same lines.Run The Final Three ReviewsRun separate content, link, and accessibility reviews, then compare all evidence against the same launch checklist.

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