Trigger: John says it is “end of day”, or asks to record the day’s work, learning, or handover.
Purpose
Leave a reliable, concise record that lets tomorrow’s session resume without reconstructing decisions from chat, a terminal scrollback, or an uncommitted diff.
Process
- Review the work actually completed today: changes made, tests or checks run, results, and what was deliberately not done. Verify material claims from the code, notes, or command output rather than relying on memory.
- Record the project-specific handover in the appropriate private/project worklog: current state, concrete decisions, outstanding work, dependencies, and safe next action. Include enough detail to distinguish completed work from proposed work.
- Update the relevant project note(s) where a fact, design decision, operational procedure, or deferred improvement belongs there. Keep domain-specific material in the project’s private notes store.
- Extract only genuinely reusable lessons into the public working-practice or programming-rule notes. Do not move private infrastructure, client, credential, host, or project detail into public notes.
- Make every new handover or improvement note discoverable: link it from its project index and, where useful, the main contents page. Read back changed notes to verify the content, metadata, and links.
- After substantial documentation work, make a bounded link-curation pass when useful: add high-value routes, move misplaced links, and remove only confirmed cruft. See README/link-curation.
- State a short end-of-day summary to John: what is safely complete, what is next, and any blocker or choice needed tomorrow.
Scope and restraint
- Do not infer a request to commit, push, create a Jira update, change infrastructure, or clean files merely because it is end of day. Report those as outstanding unless John asks.
- Do not create a general rule for a one-off project detail. General notes should record a repeatable practice with a clear future trigger.
- Use the date in the worklog title/key and distinguish observed results from assumptions or planned follow-up.
- Maintain this procedure as a useful tool: add new repeatable steps, revise unclear ones, and remove steps that experience shows are not useful. Update TRIGGERS too when the invocation needs a recognisable cue.
Minimum handover checklist
Completed work; verification performed and result; current code/operational state if known; decisions made; deferred work; blocker/owner; next safe command or action where useful.