Writing instructions
A standing responsibility is not a prompt. What changes when the same text runs fifty times.
Instructions are the part of a routine you will edit most, and the part that decides whether the result is worth reading in week six.
The difference from a chat prompt is simple: you will not be there. You cannot clarify, and the routine cannot ask. Everything the model needs must be in the instructions, the variables, or the tools.
The four things every routine should state
The outcome
Not the task — the deliverable. "Produce a prioritised brief with at most five findings" is checkable. "Review the repository" is not.
Name the format too. Recurring output is read quickly, and a stable shape is what makes it skimmable across weeks.
The evidence standard
Say what counts as support for a claim: a file path, a query, a source link, a figure with its date range. Then say what to do when evidence is missing — usually "state that it could not be verified" rather than "omit it."
This single instruction removes most of the failure modes of unattended generation.
The boundaries
Say what the routine must not do: not change code, not publish, not contact anyone, not assert causes the data cannot support, not include customer names.
Boundaries are more reliable than tool policies at shaping behaviour — the tool policy stops the action, the boundary stops the attempt — but they are not a substitute for one. Use both.
The escalation behaviour
Say what to do when the work cannot be completed: return partial results with a clear statement of what is missing, rather than inventing the remainder or failing silently.
What belongs in a variable instead
If a value changes between runs or between copies of the routine, it belongs in a variable:
| In the instructions | In a variable |
|---|---|
| How to audit a repository | Which repository |
| How to structure the report | Which reporting window |
| The voice and the banned-word list | This cycle's topic or campaign |
| What counts as evidence | The currency or locale |
The test: if you would have to edit the sentence to reuse this routine somewhere else, the changing part is a variable.
Techniques that hold up over time
Editing safely
Any change to instructions returns the routine to draft and requires a new
manual proof before it can be scheduled again. Treat that as a feature: it
means the version that runs unattended is always a version someone read the
output of.
For a routine you are actively tuning, keep a second draft routine in the same project and iterate there, so the live one keeps running while you experiment.
Length
Instructions accept 20 to 20,000 characters. Long is fine; vague is not. Most good routines land between 300 and 1,500 characters — enough for the four sections above, and little else.