Session Start

2. Check pending items (silent)

• When available, call memory_session_health_check() first and treat its output as the authoritative compact maintenance probe.
• If memory_session_health_check() reports pending review-queue items, load core/governance/review-queue.md only when you need the actual entries or the user asks about them.
• If memory_session_health_check() reports one or more folders in aggregation_due, flag them for session-end handling. At wrap-up, preview the compaction with memory_run_aggregation(dry_run=True) before deciding whether to apply summary/archive updates.
• If memory_session_health_check() reports periodic_review_due: true, note that during the greeting.
• Manual fallback when the MCP tool is unavailable: use metadata-first maintenance checks. If core/governance/review-queue.md still contains only its placeholder, skip it. Load it only when there are real pending items or the user asks about them. Check whether any ACCESS.jsonl file has reached the aggregation trigger (see core/INIT.md). If so, flag it for session-end handling. Check core/INIT.md for the last periodic review date. If overdue, note it.

3. Check write access (silent)

• If running on a read-only platform, note this and prepare to produce deferred actions at session end per core/governance/update-guidelines.md § "Read-only operation". If this is your first read-only session, also review the worked example in core/governance/update-guidelines.md § "Worked example" for the output format.

4. Build checkpoint habit (silent)

• Use memory_checkpoint as the default low-ceremony persistence tool during active work when write access is available.
• Call it after completing a major task, learning something new about the user or repo that should survive compaction, making a non-obvious decision, or spotting a pattern worth preserving.
• Treat checkpointing as a habit, not an emergency procedure. Save small but valuable state before context pressure forces a heavier sync.

5. Greet with continuity (interactive)

Greet the user in a way that reflects:

• What they were working on last time (from the recent chat summary).
• Any pending items that need attention (from the review queue).
• Any system maintenance due (aggregation, periodic review).

Keep the greeting concise — 2–3 sentences. Then ask: "Has anything important changed since last time?"

Greeting examples

Good: "Last time we were debugging that WebSocket connection issue in your dashboard — did you find the root cause? I also have a couple of review items queued up whenever you want to look at them."

Bad: "Welcome back. Your profile indicates you are a software developer who prefers TypeScript. I have loaded your identity, knowledge, and skills summaries."

The first demonstrates memory and invites continuation. The second recites data and narrates the bootstrap.

Quality criteria

• The user should feel recognized — the greeting demonstrates that memory is working.
• Pending items are mentioned naturally, not as a status dump.
• The greeting takes no more than one short paragraph before the user can speak.

Anti-patterns

• Don't recite the bootstrap. Never say "I read README.md, then CHANGELOG.md, then..."
• Don't overwhelm. If there are 5 pending review items, summarize as "a few pending review items" and offer to go through them, rather than listing all 5 up front.
• Don't fabricate continuity. If there's no prior chat history, say so honestly rather than pretending to remember.