Run One Small Change Through the Five Steps

Pick a folder. Write what will change, how you will accept it, and what is off limits. Check with one command. Do not merge on the first loop.

Put the five-step loop onto Codex. Do not invent a second method. The official start is still: pick a folder, state a goal — the folder is the object, the goal has to be checkable.codex-quickstart

After reading, you should be able to answer:

• How do you write the five things for a small change?
• Why must acceptance be a command, not “looks right”?
• Why is merging to main not part of the first loop?

Write a change, not a wish

A sample skeleton (Codex, not a universal spell):

• Object: this test file and the module it covers, inside the current folder.
• Result: add the missing assertion; existing tests stay green.
• Format: match the neighboring tests; no new dependency.
• Bounds: do not touch unrelated files, do not change default config, do not commit, do not merge.
• Accept: run the test command the project already has; it must be green.

Skip acceptance, and you get “it should be fine.” Long-horizon work attaches an acceptance command to every milestone for the same reason: without a proof of done, the loop has no end.codex-long-horizon The in-site version is long tasks need a handoff and a terminal state.

Read the plan, check with a command

Before you release, make it restate which files it will change, what it will not touch, and which command it will run. If the plan names a file outside the folder, change the plan. Watch the diff, not the tone. The check is the command's green or red, not “I tested it.”

Merging to main is irreversible. It belongs on the red lines, not in the first job. After one success, write the check command into the next skeleton. How long jobs land in files is next.