Framing
The instruction you keep
A request you make every week, identically, retyping it from memory each time.
How it goes
do it yourself- Write it once and for all, using the six lines of the instruction pattern.
- Store it in a file, not in a conversation: a conversation gets lost and cannot be corrected, a file gets re-read, dated and compared.
- Every week, paste the file first and the day’s material second, in that order and never the other way round.
The instruction, word for word
copy it, then correct itRole: horizon-scanner for a product team of six. Context: this note is read on Monday morning, in ten minutes, by people who do not follow the subject during the week. Task: sort the items below and turn them into a scanning note. Constraints: keep only what changes a decision for the team; drop the rest without mentioning it; if an item cannot be verified, say so instead of dropping it silently. Format: at most three sections, each with a one-sentence heading that carries the information, not the theme. Do not: no general conclusion, no "in summary", no adjectives of appreciation. --- this week's material below ---
- The closing separator
- It marks where the instruction ends and the material begins. Without it, a long paste is sometimes read as a continuation of the instructions.
- “read in ten minutes”
- The context describes the READING, not the subject. That is what sets the length without imposing any word count.
- “say so instead of dropping it”
- The constraint that keeps the note trustworthy over time: it turns a silence into a flag.
What you get out of it
The same quality every week, without thinking about it. You have just written a system prompt without knowing it: the only difference from the one buried inside a product is that yours is visible, dated, and yours to correct.
Going further
Keep the previous version alongside. An instruction degrades as exceptions pile up on it, and the day the answers turn, knowing when the last version that worked well dates from saves you a morning.