Context Persistence

Solve cross-session context storage and sync problems. Use when (1) isolated sessions (cron/subagent/heartbeat) lack context from main session, (2) long-runn...

Security Scan

The skill's instructions, scope, and requirements are internally consistent with its stated purpose of persisting and synchronizing context across sessions.

Purpose & Capability

Name and description match the SKILL.md: it provides file-based patterns (MEMORY.md, daily logs, progress files) and cron/payload guidance. It requests no binaries, env vars, or installs — proportional to an instruction-only persistence design.

Instruction Scope

Instructions stay within context-persistence responsibilities (read/write workspace files, embed small context into cron payloads, use progress files, locks). However, the guidance assumes writing potentially sensitive user and task data to disk without recommending access controls, encryption, or retention policies — this is a practical privacy/security concern (not an incoherence).

Install Mechanism

Instruction-only skill with no install spec or downloaded artifacts — lowest-risk install footprint and consistent with a patterns-and-guidelines skill.

Credentials

No environment variables, credentials, or config paths are requested. The skill does not ask for unrelated secrets or external API keys; its file-based approach aligns with its purpose.

Persistence & Privilege

always is false and the skill is user-invocable. It does not request persistent or cross-skill privileges or to modify other skills. Autonomous invocation is allowed (platform default) but not combined with broad credentials here.

Assessment

This skill appears coherent and useful for cross-session state, but note it centralizes data on disk. Before installing: (1) decide whether progress/daily files may contain sensitive user data — avoid putting secrets in them; (2) apply file permissions, encryption, or an access policy for memory/ directory; (3) add retention/rotation and purge rules so long-term logs don't accumulate sensitive history; (4) be careful when embedding context into cron payloads (payloads may be logged or visible to operators); (5) use atomic writes or the recommended lock pattern to avoid races. If you need stronger guarantees (encryption, audit logs, or remote secure storage), plan those controls before relying on these patterns.

Context Persistence & Cross-Session Sync

Design and implement persistent context systems that survive session boundaries.

Core Problem

OpenClaw has multiple session types with different context access:

Session	Memory Files	History	Cron Context
Main DM	✅ All injected	✅ Full	N/A
Group Chat	❌ Not loaded	✅ Partial	N/A
Cron (isolated)	❌ None	❌ None	✅ Payload only
Heartbeat	❌ None	✅ Partial	N/A
Subagent	❌ None	❌ None	✅ Task only

Result: State created in one session is invisible to others unless persisted to files.

Architecture: Three-Layer Memory System

Layer 1: Long-Term Memory (MEMORY.md)

• What: Curated facts, decisions, lessons, key state
• Who writes: Main session only
• Who reads: Main session only (injected via AGENTS.md)
• Update frequency: On significant events, periodic review during heartbeats
• Size limit: < 200 lines (context budget)

Layer 2: Daily Logs (memory/YYYY-MM-DD.md)

• What: Raw chronological notes, conversations, decisions
• Who writes: Any session that has something to record
• Who reads: Main session (at startup), heartbeats (for review)
• Update frequency: Real-time as events happen
• Size limit: Unbounded (not injected into context)

Layer 3: Task Progress Files (memory/<task>-progress.md)

• What: Structured progress for long-running work
• Who writes: Any session doing the task
• Who reads: Any session continuing the task
• Update frequency: At task boundaries (session end, checkpoints)
• Size limit: < 300 lines

The Key Insight

Files are the only cross-session communication channel. In-memory state dies with the session. Files survive.

Pattern 1: Progress Tracking

For tasks spanning multiple sessions (source code reading, data analysis, etc.)

See references/progress-tracking.md for full template.

Essential elements:

# <Task> Progress
- Total: X items
- Completed: Y items  
- Progress: Z%
## Completed List (dedup)
## Current Position / Next Steps
## Key Findings

Pattern 2: Cron Job Context Injection

Isolated cron sessions have NO access to workspace memory. Solutions:

1. Embed context in payload message (for <1KB state)
2. Read from progress files (task loads its own context)
3. Shared state file (coordination between sessions)

See references/cross-session-sync.md for patterns.

Pattern 3: Main Session Initialization

The AGENTS.md startup sequence ensures context loading:

1. Read SOUL.md (persona)
2. Read USER.md (who you help)
3. Read memory/YYYY-MM-DD.md (today + yesterday)
4. If main session: also read MEMORY.md

This is the ONLY automated context loading. Everything else must be explicit.

Quick Checklist

When designing context for a new task:

• Can this span multiple sessions? → Create progress file
• Does cron/subagent need this? → Embed in payload or file
• Is this a fact to remember? → Update MEMORY.md
• Is this a raw event? → Append to daily log
• Should future sessions know this? → Write it DOWN, never rely on memory