Automating your own practice, stack and skill
A scriptable call with no interface, lifecycle triggers and distilled memory form a stack that keeps working on its own, and a move repeated a third time deserves to become a named command.
A move repeated identically a third time no longer needs to be typed out a fourth time: it becomes a named command, invoked with a word rather than rebuilt from scratch every time.
Three layers, not one
A personal practice that keeps working on its own rests on three distinct layers. The first is the scriptable call with no interface: a task triggered by a command, without opening a chat window, that produces its result directly in a file or a terminal output. The second layer is made of lifecycle triggers, rules that run automatically at a defined moment, at the start of a session or just before it ends, without anyone needing to remember them. The third layer is distilled memory: condensed notes, read again at startup, rather than the raw transcript of everything that was said or done, which would grow without ever being read in full.
These three layers stack on top of each other: the scriptable call does the work, the lifecycle trigger decides when to launch it, distilled memory keeps what needs to be remembered from one run to the next. None of the three replaces the other two.
The three-repetition threshold
The rule that triggers the shift into a named command is simple to observe in yourself: the first time a move is made, it is an exploration. The second time, coincidence is still possible. The third time the same sequence is redone identically, word for word or nearly so, it is a pattern, and a pattern deserves a name. The example below fabricates a named command definition, to show the shape this shift from manual move to command takes.
{
"nom": "resumer-notes",
"declencheur": "manuel",
"action": "lire notes/*.md, produire un resume de 200 mots, ecrire resume.md"
}This definition contains nothing that a manual move repeated three times would not already have produced by hand. What changes is that it now carries an invokable name, and that this name avoids reconstructing the sequence from memory at the fourth run.
What the stack does not replace
An automation stack keeps working on its own on what is repetitive and verifiable. It does not replace the judgement that decides whether a result produced automatically should be published, sent or applied: that judgement remains a separate move, exercised afterwards, never delegated to the same layer that produced the result. Building a mobile application from end to end shows where this rule's material comes from: a path repeated identically for every new screen is exactly the kind of move that the third repetition turns into a named command.
The three layers of a personal automation stack
A writer notices that he has written, by hand, three weeks running, the same end-of-session summary in the same format. He writes a named command definition that reproduces this format and saves it in his configuration folder.
Write in one sentence what this situation establishes, and in one sentence what it does not establish.
What this establishes: This move establishes that a command definition now exists, capable of reproducing a format already produced three times by hand.
What this does not establish: It does not establish that this command, once run, will produce exactly the same result as the three versions written by hand, since it has not yet been run.
The three most common miscalibrations
- Too broad This move establishes that every future summary will now be generated automatically with no intervention.
- Too narrow This move establishes nothing, since a command definition written just once still proves no automation.
- Beside the point This move shows that the writer's configuration folder accepts the addition of new definitions.
- A scriptable call with no interface, a lifecycle trigger and distilled memory form three distinct layers, and none replaces the other two.
- The third identical repetition of the same move is the signal that triggers its shift into a named command.
- A named command carries an invokable name and avoids reconstructing the sequence from memory at every new run.
- The judgement that decides to publish, send or apply an automatically produced result remains a separate move, exercised afterwards.
Spot a sequence you have redone three times this week in the same words or the same steps, and write its definition right now as a named command, even if you do not run it yet.