A prompt is half a conversation. You send it, read the reply, and steer. If the model misunderstands, you say "no, I meant the last two weeks" and carry on. The steering is invisible because it feels like nothing — but it is doing most of the work.
Put that same text on a schedule and the steering disappears. The instruction now has to stand on its own, at 09:00 on a Monday, against inputs you have not seen, with nobody available to clarify.
Almost every scheduled routine that disappoints is a prompt that never got rewritten for that situation.
What actually breaks
Ambiguity gets resolved silently. "Recent changes" means whatever the model decides it means this week. You will not notice, because the output looks the same either way.
Format drifts. Without a stated structure, week three arrives as prose, week four as a table, week five as a numbered list. Nothing is wrong with any of them, and none of them are comparable.
Absence looks like success. Asked to "review the repository," a model can produce a plausible review having read very little. The result reads fine. The work did not happen.
Uncertainty gets smoothed over. Missing data becomes a confident sentence rather than a flag, because nothing in the instruction told it what to do instead.
Five edits that fix most of it
1. Name the deliverable, not the task
"Review the repository" describes an activity. "Produce a prioritised brief of at most five findings, each with a file path, a severity, and a recommended action" describes something you can hold up and check.
Cap the output while you are there. A maximum forces prioritisation; without one, recurring output grows until nobody reads it.
2. Define the window in absolute terms
Replace "recent" with something a machine can resolve: "changes merged since the previous Monday," "the completed calendar quarter," "the last 30 days ending yesterday."
Then require the routine to state the window it used in the output. When the numbers look strange in week nine, you want to know immediately whether the range moved.
3. Set an evidence standard
Say what counts as support: a file path and line, the query that produced the figure, a source link, a date range.
Then say what to do when evidence is missing — usually "state that it could not be verified," never "omit it." This single instruction converts the model's uncertainty into information for the reader instead of confident filler, and it is the highest-value sentence in most routines.
4. Write the boundaries down
Say what must not happen: do not change code, do not publish, do not contact anyone, do not assert a cause the data cannot support, do not name customers.
Boundaries in the instructions and permissions in the tool policy do different jobs. The tool policy stops the action. The boundary stops the attempt — which also stops the routine spending three of its steps trying.
5. Use a banned-word list instead of adjectives
"Write confidently" is not checkable. A list of words never to use is something the model can verify against its own draft before returning.
The same trick works for structure: numbered sections the model can count are more reliable than "well organised."
A worked example
Before — a perfectly good prompt:
Review our repo for security issues and let me know what you find.After — an instruction that can run unattended:
Audit {{repository}} for security risk introduced or materially changed since
the previous Monday.
Produce: at most five findings, ranked by severity. Each finding states the
file path, what changed, why it matters, and a recommended action.
Evidence: every finding cites a file path or commit. If something looks risky
but cannot be confirmed from the repository, list it separately under
"Unverified" rather than omitting it or asserting it.
Boundaries: read only. Do not modify files, open pull requests, or contact
anyone. Do not restate long-standing issues unless they changed this week.
If the diff window contains no relevant changes, say so in one line rather
than finding something to report.Four times longer, and the difference in week six is not subtle.
That last paragraph deserves special mention. A model asked to find problems will find problems. Explicitly permitting "nothing changed" is what stops a weekly audit from manufacturing findings on a quiet week.
Where the values go
Notice {{repository}}. Everything that varies between runs — the repo, the
reporting window, the campaign, the currency — belongs in a variable, not in
the sentence. The test: if you would have to edit the prose to reuse this
routine somewhere else, the changing part should be a variable.
Prove it before you schedule it
You cannot tell whether an instruction survived the rewrite by reading it. You find out by running it once and reading the trace — the actual sequence of tool calls, not only the final text.
A result that reads well and made no tool calls is a generated opinion. That is worth catching before it arrives every Monday for a quarter.
More on this in Writing instructions and Variables.