Source: raw/Claude_Code_goal_Just_Dropped_and_it_Can_Build_Literally_Anything.md — YouTube tutorial 0lw8KTx8KS8 by Chris (15 years designing apps + advising startups; runs the plaid.build / “productled AI development” community). Chris’s /goal guide for the Codex CLI is referenced as a non-technical companion read.
A side-by-side walkthrough of /goal in both Claude Code AND Codex CLI, building the same full app (described in docs/prd.md + docs/product-roadmap.md) in parallel folders. Claude Code’s /goal command is positioned as stolen-directly-from-Codex — a completion-condition primitive that lets the agent loop autonomously across 40-80 tasks for hours or days, with a small fast model checking the completion condition after each turn. Framed as the evolution of the Ralph loop (manual user-driven task iteration) into a model-driven goal-converged session.
Key Takeaways
What /goal does (Anthropic’s official wording, surfaced via Chris)
“The /goal command sets a completion condition and Claude keeps working with it without you prompting each step. After each turn, a small fast model checks whether the condition holds and if not, Claude starts another turn instead of returning control to you. The goal clears automatically once the condition is met.”
- Completion-condition primitive — declare the end state in plain English; the agent checks after each turn whether it’s reached.
- Up to 4,000 characters for the condition string itself.
- Auto mode pairing —
/goalworks hand-in-hand withauto-mode, which suppresses tool-call permission prompts so the agent can keep working without constant user approval. See auto-mode for the auto-mode reference. - Same primitive in Codex CLI — same name, same semantics. Claude Code’s
/goalis a direct port. Both ship official/goaldocumentation.
From Ralph loop to /goal
- Ralph loop (prior pattern) — manually loop the coding agent against a defined task list. Agent completes one task, returns control to user, user prompts the next task. Repeat.
/goalevolution — agent self-loops until the completion condition is verified by the fast checker model. No user-in-the-loop per task.- This collapses the 40-80-task build cycle from minutes-per-task user interaction to a single “start” then walk away.
How to write a strong goal condition
Per Codex documentation surfaced in the video:
- Measurable end state. The agent must know what “done” means before it starts.
- Bigger than one prompt, smaller than an open-ended backlog.
- Define four things: what to achieve, what to change, how to validate progress, when to stop.
- Add constraints that matter — files/areas that must NOT be touched.
The meta-prompt for goal generation
Chris’s tip when you’re not sure what goal to ask for:
“Based on what you know about me, what goals would be beneficial to me, and can you help me structure a goal before I get started?”
Use Claude Code itself (or Codex) to brainstorm the goal shape before invoking /goal.
Codex’s example goal that Chris adopts (prototype creation)
“Implement plan.md creating tests for each milestone and verifying the output with playwright interactive.”
His adapted version for the parallel build demo:
“Implement the product roadmap.md. Build each task in the task list and then verify the output before moving on to the next task. When all tasks in the product roadmap are complete, this is the end of your goal.”
Recommended project scaffold before invoking /goal
Chris drops a specific 3-file scaffold in the repo root:
| File | Purpose |
|---|---|
CLAUDE.md (Claude Code) or agents.md (Codex) | The “four Karpathy rules for CLAUDE.md/agents.md” — error-reduction rules at the repo root. Reduces coding errors from the agent. |
docs/prd.md | Product requirements document — describes WHAT to build. |
docs/product-roadmap.md | Task list — 40-80 items the agent works through, ticking off each. |
docs/design.md | Design direction generated from image references via Chris’s plaid skill (plaid.build). Follows Google’s open-source design.md format. |
Workflow recommendation: plan mode first, then /goal
- Open plan mode in Claude Code or Codex first.
- Have the agent generate a plan with the verifiable end-condition built in.
- Then
/goalagainst that plan. - This prevents “too open-ended goal → not enough context to work correctly” failure mode.
The two parallel builds in the demo
Chris runs the exact same /goal in both Claude Code and Codex CLI against the same scaffold (PRD + roadmap + design.md):
/goal Build the complete app outlined in docs/prd.md following the tasks
on product-roadmap.md until all of the tasks on the program are complete
and verified. Use design.md for the frontend design direction. This is a
fresh Next.js app build.
Two folders, two agents, same input → comparison of how each performs. (Final comparison results are in the full transcript past line 300 — not captured here on first read.)
Worked example — bank-statements categorization (second-creator walkthrough, 2026-05-19)
A separate /goal walkthrough on YouTube (aMfig5cKOtY) frames the command around a concrete bank-statements example: a year of PDF statements where every transaction needs to be pulled out, categorized (food / gas / subscriptions / etc.), and assembled into a monthly-spending spreadsheet with totals. Without /goal, Claude completes the first statement then waits — “keep going” on a loop, hour+ of babysitting. With /goal, the finish line is declared once:
“Every file in my receipts document has been categorized and summarized into a spreadsheet that exists with totals.”
…and the agent runs turn-after-turn unattended until the boss agent verifies the condition holds. This walkthrough also surfaces the worker + boss two-agent architecture explicitly: the main model (Opus or Sonnet) is the worker doing the actual file work; a separate small fast model is the boss that reviews after every turn and asks “is the goal met yet?” — if not, it tells the worker exactly why and kicks off another turn. Pairs naturally with auto-approve for the full hands-off experience. Bare /goal (with no condition) acts as a dashboard surface, showing elapsed time + turn count + tokens used.
The PDF-to-categorized-spreadsheet example is the cleanest non-coding use case the wiki has captured so far — most /goal content shows software builds (the Chris walkthrough above). Worth keeping in the example library because it shows the same primitive lifting a tabular-data ingestion workflow.
Open Questions
- Final comparison verdict — Claude Code vs Codex CLI on the same
/goaltask. Transcript continues past the initial setup but final results not extracted here. Worth a Tier-1 refresh after a second read. - plaid.build skill detail — Chris references his own skill for generating
design.mdfrom image references. Pattern fits but skill internals not in this transcript. - The “four Karpathy rules” for CLAUDE.md — Chris references but doesn’t enumerate. Likely a subset of the Karpathy LLM-wiki guidance.
- buildgreatproducts.com /goal guide URL — referenced as a non-technical companion to the official Codex docs.
- Task-count claim (40-80 per roadmap) — empirical range Chris cites; not from official Anthropic guidance.
Related
- whats-new-2026-w20 —
/goalshipped in v2.1.139 (Week 20) - whats-new-2026-w21 —
/goalsubagent-race fix in v2.1.143 (Week 21) - auto-mode — companion primitive that suppresses permission prompts during goal loops
- chris-2026-05-coding-workflow-update — same creator (Chris); previous walkthrough on his solo-dev stack
- cli-reference — the canonical
claudebinary surface - agent-teams — adjacent multi-agent primitive
- karpathy-techniques-for-claude-code — the “four rules” Chris references
- subagents — the primitive
/goalorchestrates underneath
Try It
- Build the scaffold first. Drop a
docs/prd.md+docs/product-roadmap.md(with 40-80 tasks) +docs/design.md(Google open-source format) +CLAUDE.md(Karpathy rules) into your repo root. - Use plan mode to generate the goal condition. Enter plan mode first; ask Claude Code to draft a
/goalcondition that maps to the roadmap. Don’t write the goal cold. - Pair with auto-mode so permission prompts don’t interrupt the loop — see auto-mode for the safety rules to set before doing this.
- Start with the prototype-creation pattern from Codex docs:
“Implement plan.md creating tests for each milestone and verifying the output with playwright interactive.”
- Add constraints — explicitly list files/areas the agent must not touch. The condition string can be up to 4,000 characters; use them.
- For a side-by-side test — duplicate the scaffold into two folders, run the same
/goalin Claude Code and Codex CLI. Compare results (Chris’s exact methodology). - Use the goal-brainstorm meta-prompt when stuck on what to ask: “Based on what you know about me, what goals would be beneficial?” Then have the agent help structure it.