01The operator stated the same order twice in one day, in different words
The material is two requests from September 9, 2026. In the first, the operator asked the AI to move on to building the English site, one step after the other, once the Japanese version was done.
The second was sent as a request to be picked up later. It opened by saying this hardly needed saying, repeated that English came next, and asked that English begin only after the Japanese go-live had fully finished.
The limits of this material matter. Only the requests survive here. These two records cannot tell us whether the AI ever broke the order, or why the operator wrote the second request. What they do show is one order written twice in a day, with a more precise condition the second time.
That is enough to extract a pattern anyone can use. When you feel the urge to restate an order, first look at what the last version left out.
02The second request added a start condition, not a new order
Split the two requests into parts and the order itself has not moved. Japanese comes first and English second. What changed is how the moment to start English is described.
| Aspect | First request | Second request |
|---|---|---|
| Earlier task | Japanese version | Japanese version |
| Finish condition | Once it is done (which state is not stated) | After go-live has fully finished |
| Next task | Building the English site | The English version |
| Run side by side? | No, one after the other | No, one after the other |
"Done" has a wide range. It could mean the draft is written, the page is assembled, or the page is published. "Go-live has fully finished" leaves far less room for different readings.
03A vague start condition lets corrections miss the next task
Order rules matter when the later task builds on the result of the earlier one. Correct the Japanese just before publication, and an English version already under way will not contain that correction. The same passage gets fixed twice, and anything missed remains as a mismatch between the two versions.
Aligning the versions shows up in the record too. On the same September 9, the operator separately asked for a job that would find and resolve differences between the Japanese and English pages. The record does not link that job to the order rule. It does show that keeping two versions aligned had become a separate task of its own.
The other cost is the user's attention. A rule that lives only in your head has to be remembered and typed each time, and on the day you forget, it might as well not exist. An order you consider too obvious to mention still reaches the AI only as far as you wrote it down.
04An order rule is one sentence with four parts
In this episode, an order rule means a promise that holds repeatedly, of the form "this task comes after that one", written as one sentence with these four parts.
Earlier task
Name the work the next step builds on, such as publishing the Japanese version.
Finish condition
Describe a state someone can check and answer yes or no.
Next task
Name the work that begins once the condition is met.
Not alongside
State plainly what must stay untouched until the condition is met.
The second part carries the most weight. Anthropic's Claude Code documentation recommends instructions concrete enough to verify, and offers "Use 2-space indentation" in place of "Format code properly". For an order, that means "after checking the published page" in place of "when finished".
The idea has a boundary. An instruction that sets the sequence for one piece of work, once, is not a rule in this sense. Forcing an order on independent tasks slows down work that could run in parallel. Make a rule only when the later task builds on the earlier result and the same order keeps coming back.
05In material review, it applies when derivatives follow a settled source
Pharmaceutical material production contains orders of the same shape. The table below applies the pattern as an illustration. Actual conditions should follow each company's own procedures.
| Situation | Vague wording | Wording that works the first time |
|---|---|---|
| Source material and English version | Translate it once the Japanese is ready | Start the English draft after approval of the Japanese material is recorded in internal review. Do not translate before then |
| Brochure and briefing slides | Do the slides when the brochure settles | Build the slides from the final brochure once it is confirmed, and state the version number used |
| Package insert revision and materials | Fix the materials when the revision arrives | After receiving the revised insert, list the affected materials. Do not edit any text until the person responsible has checked the list |
In each example, the AI's part ends at a draft or a list. Whether something is approved is for the reviewer to decide, not the AI. Writing a human decision into the finish condition lets you instruct the AI not to move past it.
06An order given in conversation may not last until the next task
Product design helps explain why orders get restated. Take Claude Code as the example. Its documentation says each session begins with a fresh context, and that an instruction given only in conversation can disappear after a long conversation is compacted.
Writing it in a settings file does not make it absolute either. The same documentation says the AI treats that file as context rather than enforced configuration, and that strict compliance is not guaranteed, especially for vague or conflicting instructions.
So choose the location by what a broken order would cost. Claude Code's documentation advises that anything that must happen every time should be enforced by the tooling, not left as an instruction the AI weighs. Software automation offers the same idea. In GitHub Actions, you can declare that a job runs only after another job succeeds. If the earlier job fails, the later one is skipped.
Different products work differently. Check your own AI's documentation to learn what carries over to the next conversation.
07From tomorrow: turn an order you stated twice into a sentence, then choose its home and its stop
There are four steps.
- Find the order you restated. Claude Code's documentation also lists anything you have had to correct twice as a candidate for the always-loaded file. Treat the second time as the signal to look for what the first version lacked.
- Write it as a four-part sentence. Use this form: "After X reaches (a state you can check), start Y. Leave Y untouched until then." Add the reason in a few words. Anthropic's documentation explains that giving the motivation behind an instruction helps produce responses better aimed at your goal.
- Keep it where it loads every time. If your AI has project instructions or an always-read settings field, put it there. If it does not, make it part of your standard request text.
- Add a stop to orders that are hard to undo. If publication or sending outside the company is involved, place a human approval or an automated check before the next task.
Then test it once. In a new conversation, ask the AI what it may start next, and have it state the condition in its own words. If the answer drifts, fix the wording at that point. A single sentence does not guarantee compliance, so the check before publication stays with a person.
- When you restate an order, look at the start condition before repeating yourself. Replace "when done" with a state that can be checked.
- An order rule is one sentence with four parts: earlier task, finish condition, next task, and what must not run alongside. Write one only for orders that have a real dependency and keep coming back.
- Instructions given in conversation may not last. Keep the rule where it loads every time, and add a human approval or an automated check to orders that are hard to undo.
Repeating an order to an AI is not only a question of what the AI retains. It also signals a finish condition that is still in your head and not yet on the page. Write the condition down and give it a home, and the next request can start without retyping the order. Confirming that the order was kept remains the user's job.
- Anthropic. How Claude remembers your project. Claude Code Docs. https://code.claude.com/docs/en/memory
- Anthropic. Best practices for Claude Code. Claude Code Docs. https://code.claude.com/docs/en/best-practices
- Anthropic. Prompting best practices. Claude Developer Platform Docs. https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices
- GitHub. Using jobs in a workflow. GitHub Docs. https://docs.github.com/en/actions/how-tos/write-workflows/choose-what-workflows-do/use-jobs