A chat transcript is not a playbook
A transcript records everything that happened, including dead ends. A useful playbook records what a future operator needs to recognise the situation, choose the shortest known safe route and prove that the job is actually complete.
Start only after the result is verified
Do not promote an unverified attempt into reusable procedure. First establish the postcondition: the device is visible, the driver is working, the PC is stable, the files are recovered, the remote session is gone or whatever the real success condition was.
The eight fields worth keeping
- Trigger: what symptom or request starts this playbook?
- Environment: which operating system, hardware class, application or device family mattered?
- Pre-checks: what can be observed safely before changing anything?
- Shortest verified path: which sequence actually solved the problem?
- Verification: what independent evidence proves success?
- Stop conditions: when does the playbook no longer fit?
- Cleanup: what temporary state or access must be removed?
- Learning: what should be tried earlier or avoided next time?
Example: a USB device that looked dead
A laser engraver that was not visible to its application did not need random application reinstall attempts. The useful sequence was lower-level: confirm Windows USB enumeration, restore the serial path, identify the COM port, verify the controller protocol and only then configure the engraving software.
Example: a PC prepared for sale
A resale PC needs more than “Windows boots”. A reusable closeout playbook checks hardware identity, problem devices, updates, security state, startup load, storage health, drivers, activation, practical stability and finally removes every temporary support artefact before handover.
Make verification part of the procedure
A service removal is not complete because a command returned zero; it is complete when the service is absent. A USB driver is not fixed because setup completed; it is fixed when the expected device and protocol respond.
Keep the learning explicit and user-controlled
This is not hidden self-training. The useful experience is written down as an inspectable procedure that can be corrected, versioned or discarded. That keeps operational learning portable across model changes instead of burying it in one conversation.
A compact post-task template
| Field | Question |
|---|---|
| Goal | What exact state did the user need? |
| Signal | How do we recognise the same problem again? |
| First checks | What can be observed safely before mutation? |
| Known path | What sequence worked? |
| Proof | What read-back proves success? |
| Failure modes | What misleading symptoms or dead ends occurred? |
| Cleanup | What temporary state must be removed? |
| Next-time improvement | What can be done earlier, faster or more safely? |
The useful outcome
The next session begins with accumulated operational knowledge instead of repeating discovery from zero. The human still decides whether the old procedure applies; the AI gets a better starting point because the previous work produced evidence and a reusable route.