The Core Laws
A repeated instruction is a missing rule
If you have said it twice, stop saying it. Write it down where the machine reads it every time.
The second time you type the same correction, the problem is no longer the machine's. A session-bound colleague cannot accumulate your preferences; every session you re-teach it is a tax you have chosen to keep paying by hand, forever. Repetition is the signal: what you just said twice is not an instruction, it's a rule that hasn't been written down yet.
Anything that persists across sessions is where corrections go to become permanent: a preferences file, a project brief, custom instructions, a template. The best ones graduate past reminder into structure, a constraint the system enforces rather than a request the machine considers. A rule it reads every session is good; a rail it cannot leave is better.
How to practice it
Notice the second time.
The first correction is conversation. The second is a defect in your setup, and typing it a third time is choosing the defect.
Write it where it's read.
Standing instructions, project files, templates: wherever the machine looks every session without being told. That's where the correction lives now.
Prefer rails to reminders.
Where the platform allows it, make the wrong thing impossible instead of discouraged: a locked setting, a required field, a check that blocks.
Prune the rulebook.
Standing rules that stopped earning their keep are noise that buries the ones that matter. Retire them like you retire dead code.
Deep scripture: Codeuteronomy V — A repeated instruction is a missing constraint