| name | Memory Management |
| description | Context hygiene, memory flush before compaction, sub-agent lifecycle, and daily operations patterns.
Use when: Context is growing large and you need to prepare for compaction, switching between unrelated tasks, or establishing a daily operations routine. Also use when spawning sub-agents for long tasks.
Don't use when: Debugging a specific issue (use the appropriate troubleshooting skill). Don't use for deploying changes (use gitops-deploy). This is an internal operations pattern, not a diagnostic tool.
Outputs: No external artifacts. This skill guides internal behavior — writing to workspace files, spawning sub-agents, and managing context.
|
| requires | [] |
Memory Management
Routing
Use This Skill When
- Context window is getting large and compaction is approaching
- Switching from one task to a completely different topic
- Starting a new session and need to reload context
- Spawning a sub-agent for a long-running task
- Need to persist important findings before they're compacted away
Don't Use This Skill When
- Debugging a pod, Flux, or CI issue → use the specific skill
- Deploying changes → use gitops-deploy
- Reviewing sessions → use session-review (robert)
- This is about managing YOUR OWN context, not the user's data
Context Hygiene
Before Starting a New Task
Run /compact to clear stale context before switching topics. This prevents hallucination from prior task context bleeding into the new one.
After Configuring Something
Commit important details to memory immediately. Verify by repeating the key facts back. Don't rely on session context surviving — compaction or restarts will lose it.
When Context Seems Incomplete
Search session memory before asking the user to repeat themselves:
- Check recent conversation for relevant details
- Review workspace files that may contain the answer
- Only ask after confirming the info isn't available
Sub-Agents for Long Tasks
Spawn sub-agents for tasks that may exceed session timeout (60 min idle):
- Scheduled/cron monitoring tasks
- Long-running build watches
- Periodic health checks
Sub-agents run independently and won't be killed by the parent session timing out.
Main agent → spawns sub-agent for monitoring
Main agent session can idle/timeout
Sub-agent continues running
Memory Flush Before Compaction
When context is getting large and compaction is imminent, flush important state to persistent storage:
- Write key findings to workspace files (MEMORY.md, or task-specific files)
- Update any tracking documents
- Log decisions and their rationale
Standard flush locations (mkdir -p /tmp/outputs first):
/tmp/outputs/<task>.md — temporary task artifactsworkspaces/<agent>/MEMORY.md — persistent learned knowledge- Workspace skill files — if you learned something about a skill's domain
This ensures nothing critical is lost when the context window compresses.
Daily Operations Pattern
- Start of session: Review workspace files for context, run health checks
- During work: Commit decisions and findings to memory as you go
- Before idle: Flush any uncommitted knowledge to workspace files
- On return: Check workspace files and events since last active
Memory Search
When looking for prior context:
- Check workspace files first (persistent across restarts)
- Search session memory for recent interactions
- Check pod logs for operational history:
kubectl logs -c openclaw --tail=200
- Review Kubernetes events:
kubectl get events -n openclaw --sort-by='.lastTimestamp'
Compaction Design Principles
From OpenAI's guidance on long-running agents:
- Use compaction as a default primitive, not an emergency fallback
- Write intermediate findings to disk before they're compacted away
- Design for continuity — assume context will be compressed
- Keep running tallies in files, not just in context
