TPEE Toptronic® Prompt Engineering Editor

91. Why You Must Use the Handover System from the Toptronic® LLM Rules

Understand how the Toptronic® handover convention gives every new session a complete picture of project status, and how the accumulated handovers become a full, readable history of what was done, when, and how.

By Jacques Botte, founder of Toptronic®. Last updated 19 September 2026.

The lesson

The Toptronic® LLM Rules contain a handover convention (the `cession_handover.md` file, where "cession" means a long-running session). It defines what must be produced when a session ends: a handover that lets the next LLM session continue the project without loss of context or performance. The rule is blunt for a good reason — a session that ends without a handover throws away most of what it just learned, and the next session pays to relearn it, badly.

A handover is triggered at three moments: when a session has grown so long that performance starts to degrade, when you explicitly ask for one, and when a major milestone is reached and a checkpoint is useful. The idea is to end the session while it is still competent, not after it has started forgetting its own earlier work. Ending on your terms turns a natural weakness of LLM sessions into a routine administrative step.

The deliverables of a handover are concrete. First, the repository itself must be current: all files saved into the working directory, all conventions applied. Second, the history logs — `History_Of_Chats_XXX.md` and `History_Of_Actions_XXX.md` — receive their final entries, so the last user requests, the LLM's actions, and their outcomes are all recorded with machine timestamps (ISO 8601, with timezone) and build numbers. Third, the inventory of files and the directory-structure document are updated, with new or changed files marked as such. Fourth, the documentation is refreshed, build numbers incremented, and copyright and "about" material kept current.

The history files are worth a closer look because they are the raw material of the project's story. The Chats convention records what was asked and what the LLM replied; the Chats-And-Actions convention records what was asked, what was done, and what resulted, in a fixed entry format: `[YYYY-MM-DD HH:MM:SS TIMEZONE] [Build: XXX]`, then `User Request:`, `LLM Action:`, and `Result/Notes:`. Files use either dated descriptive names (`2026-05-11_Database_Design_Discussion.md`) or 3-digit sequence numbers (`_001`, `_002`), and every file rolls over at 500 lines with a continuation note. Those rules exist so that the logs sort correctly, stay readable, and never grow into an unsearchable monolith.

Why a handover per session beats "the next session will just look at the code": the code shows the current state but not the trajectory. It does not say which approach was tried and rejected, why a build number jumped, or which bug was fixed in which session. The handover plus the history logs carry exactly that. A well-formed handover answers the questions the next session would otherwise waste its first hour guessing at: where is the project, what was done last, what is open, and what should I do first.

Accumulated over months, the saved handovers become something larger: a full project history. Read in date order, they tell you what was done, at which session, and how — every milestone with its timestamp and build number, every reversal with its reason. When a regression appears, you can find the session where the relevant area changed. When you write release notes or documentation, the handovers are the source material. No separate effort is needed to maintain this history; it is a free by-product of ending each session properly.

Two improvements make the system even stronger in practice. Write a short "next steps" section at the top of every handover — three to five specific, actionable items — so the next session has an immediate starting point instead of inferring one. And state the working directory path and the key file locations explicitly in the handover, so the new session's first action is a bounded read of exactly the right places, combining the handover rule with the bounded-work rule of lesson 89.

The habit loop, then, is a fixed end-of-session ritual: finish the work, update the history logs with timestamps and build numbers, refresh the inventory and structure documents, save everything inside the working directory, write the handover with status and next steps, and commit. Five minutes of discipline buys the next session a warm start — and buys the project, session by session, a complete and honest history of itself.

Check yourself

Question 1: When should a handover be produced in a long-running session?
  1. Only when the user explicitly threatens to close the session
  2. Only after the project is completely finished
  3. At the three defined trigger points: when session performance degrades, when you explicitly request one, and at major milestones — correct
  4. Randomly, whenever the LLM feels like it

Answer: At the three defined trigger points: when session performance degrades, when you explicitly request one, and at major milestones

The convention defines three triggers — degradation, explicit request, and milestone checkpoints — so sessions end on your terms while they are still competent.

Question 2: What do the Toptronic® history conventions require in each log entry?
  1. A machine timestamp in ISO 8601 format with timezone, plus the current build number, in a fixed structure — correct
  2. Only the date, written in any style you like
  3. A screenshot of the chat window
  4. Nothing — history files are optional

Answer: A machine timestamp in ISO 8601 format with timezone, plus the current build number, in a fixed structure

Entries follow the format `[YYYY-MM-DD HH:MM:SS TIMEZONE] [Build: XXX]` with `User Request:`, `LLM Action:` (or `LLM Reply:`), and `Result/Notes:` — plus 500-line rollover and strict file naming.

Question 3: What is TPEE's role in the handover and history system?
  1. TPEE automatically generates handovers and uploads them to a server
  2. TPEE stores the history logs in its own database
  3. TPEE writes the handover files on your behalf at session end
  4. None: TPEE is strictly offline and never calls external services — you create and maintain the handover and history files yourself, outside the app — correct

Answer: None: TPEE is strictly offline and never calls external services — you create and maintain the handover and history files yourself, outside the app

The handover system is a discipline applied in your editor and LLM sessions, entirely outside TPEE; the app itself makes zero network calls and only documents the conventions.

← Previous lesson · All 91 lessons

The full course — 91 lessons and 273 quiz questions — ships inside the app. Get TPEE to study it offline.