{ "schemaVersion": "1.0", "item": { "slug": "context-management", "name": "Context Management", "source": "tencent", "type": "skill", "category": "AI 智能", "sourceUrl": "https://clawhub.ai/marcus-daemon/context-management", "canonicalUrl": "https://clawhub.ai/marcus-daemon/context-management", "targetPlatform": "OpenClaw" }, "install": { "downloadMode": "redirect", "downloadUrl": "/downloads/context-management", "sourceDownloadUrl": "https://wry-manatee-359.convex.site/api/v1/download?slug=context-management", "sourcePlatform": "tencent", "targetPlatform": "OpenClaw", "installMethod": "Manual import", "extraction": "Extract archive", "prerequisites": [ "OpenClaw" ], "packageFormat": "ZIP package", "includedAssets": [ "SKILL.md", "references/config-guide.md", "references/operation-costs.md", "scripts/context-checkpoint.sh" ], "primaryDoc": "SKILL.md", "quickSetup": [ "Download the package from Yavira.", "Extract the archive and review SKILL.md first.", "Import or place the package into your OpenClaw setup." ], "agentAssist": { "summary": "Hand the extracted package to your coding agent with a concrete install brief instead of figuring it out manually.", "steps": [ "Download the package from Yavira.", "Extract it into a folder your agent can access.", "Paste one of the prompts below and point your agent at the extracted folder." ], "prompts": [ { "label": "New install", "body": "I downloaded a skill package from Yavira. Read SKILL.md from the extracted folder and install it by following the included instructions. Tell me what you changed and call out any manual steps you could not complete." }, { "label": "Upgrade existing", "body": "I downloaded an updated skill package from Yavira. Read SKILL.md from the extracted folder, compare it with my current installation, and upgrade it while preserving any custom configuration unless the package docs explicitly say otherwise. Summarize what changed and any follow-up checks I should run." } ] }, "sourceHealth": { "source": "tencent", "status": "healthy", "reason": "direct_download_ok", "recommendedAction": "download", "checkedAt": "2026-04-30T16:55:25.780Z", "expiresAt": "2026-05-07T16:55:25.780Z", "httpStatus": 200, "finalUrl": "https://wry-manatee-359.convex.site/api/v1/download?slug=network", "contentType": "application/zip", "probeMethod": "head", "details": { "probeUrl": "https://wry-manatee-359.convex.site/api/v1/download?slug=network", "contentDisposition": "attachment; filename=\"network-1.0.0.zip\"", "redirectLocation": null, "bodySnippet": null }, "scope": "source", "summary": "Source download looks usable.", "detail": "Yavira can redirect you to the upstream package for this source.", "primaryActionLabel": "Download for OpenClaw", "primaryActionHref": "/downloads/context-management" }, "validation": { "installChecklist": [ "Use the Yavira download entry.", "Review SKILL.md after the package is downloaded.", "Confirm the extracted package contains the expected setup assets." ], "postInstallChecks": [ "Confirm the extracted package includes the expected docs or setup files.", "Validate the skill or prompts are available in your target agent workspace.", "Capture any manual follow-up steps the agent could not complete." ] }, "downloadPageUrl": "https://openagent3.xyz/downloads/context-management", "agentPageUrl": "https://openagent3.xyz/skills/context-management/agent", "manifestUrl": "https://openagent3.xyz/skills/context-management/agent.json", "briefUrl": "https://openagent3.xyz/skills/context-management/agent.md" }, "agentAssist": { "summary": "Hand the extracted package to your coding agent with a concrete install brief instead of figuring it out manually.", "steps": [ "Download the package from Yavira.", "Extract it into a folder your agent can access.", "Paste one of the prompts below and point your agent at the extracted folder." ], "prompts": [ { "label": "New install", "body": "I downloaded a skill package from Yavira. Read SKILL.md from the extracted folder and install it by following the included instructions. Tell me what you changed and call out any manual steps you could not complete." }, { "label": "Upgrade existing", "body": "I downloaded an updated skill package from Yavira. Read SKILL.md from the extracted folder, compare it with my current installation, and upgrade it while preserving any custom configuration unless the package docs explicitly say otherwise. Summarize what changed and any follow-up checks I should run." } ] }, "documentation": { "source": "clawhub", "primaryDoc": "SKILL.md", "sections": [ { "title": "Context Management", "body": "Prevent context exhaustion, enforce spawn discipline, and make compaction survivable." }, { "title": "Core Concepts", "body": "Fixed baseline: Typically 5-15% of context consumed before any conversation — system prompt, workspace files, skill descriptions, tool definitions. Varies by setup (more skills/files = higher baseline).\n60/40 rule: ~60% of consumed context is tool outputs, ~40% conversation. Tool outputs are the primary target for savings.\nCompaction is lossy: Summaries stack cumulatively. Each cycle raises the floor. After 3+ compactions, summaries alone can consume 30%+ of context.\nSub-agents are disposable context: A sub-agent can burn most of its context investigating something; only the summary (~500 tokens) enters main context.\n\nAll percentages are relative to the model's context window. Check session_status for actual window size and usage." }, { "title": "When Context Pressure Rises", "body": "After every tool-heavy operation (>5 tool calls), assess:\n\nRun session_status to check usage\nIf below 50%: continue normally\nIf 50-70%: spawn sub-agents for remaining tool-heavy work (>3 tool calls)\nIf 70-85%: spawn sub-agents for ANY tool work (>1 tool call). Warn user.\nIf above 85%: write checkpoint (see below), suggest /compact or /new" }, { "title": "\"What's Eating My Context?\" — Estimation Method", "body": "Cannot get exact per-component breakdown. Estimate:\n\nFixed baseline: ~5-15% (system prompt + workspace files + skills + tools)\nPer user message: ~100-500 tokens each\nPer assistant response: ~200-1000 tokens each\nPer tool call result: ~500-5000 tokens each (exec/read heavy, search light)\nCompaction summaries: ~2000-5000 tokens each (cumulative!)\n\nCount messages and tool calls in recent history, multiply by midpoint estimates. Report as ranges, not false precision. For per-operation cost detail, read references/operation-costs.md." }, { "title": "Spawn Policy", "body": "If .context-policy.yml exists in workspace root, use it as guidance for spawn thresholds and task categories. Otherwise use these defaults:\n\nAlways spawn (regardless of context level):\n\nTest suites (>3 tests)\nMulti-file audits (>5 files)\nBuild/deploy pipelines\nResearch tasks (web search + analysis)\nBulk file operations\n\nNever spawn (keep in main session):\n\nSingle commands\nConversations / discussions\nQuick edits (1-3 files)\nStatus checks\nTasks requiring user input mid-execution\n\nContext-dependent (spawn when context exceeds threshold):\n\nAbove 50%: spawn if task involves >5 tool calls\nAbove 70%: spawn if task involves >2 tool calls\n\nWhen spawning, write detailed task descriptions. Sub-agents have no conversation context — they only know what the task field tells them." }, { "title": "Pre-Compaction Checkpoint", "body": "Before compaction or /new, write .context-checkpoint.md in the workspace root (the agent reads this post-compaction):\n\n# Context Checkpoint — {date} {time}\n\n## Active Task\n{what you were doing}\n\n## Key State\n{bullet list of current state — what's done, what's in progress}\n\n## Decisions Made This Session\n{numbered list of decisions with rationale}\n\n## Files Changed\n{list of files modified this session}\n\n## Next Steps\n{what to do after resuming}\n\nThis file survives compaction. On session start or post-compaction, check for it and use it to restore context. Delete after consuming.\n\nCoordination with OpenClaw memoryFlush: OpenClaw may fire its own pre-compaction flush (writing to daily log). The checkpoint is complementary — the flush saves to the daily log, the checkpoint saves structured resume state. Both should exist. If the memoryFlush fires first, compaction may already be in progress. For critical sessions, write checkpoints proactively at 75%, don't wait for 85%.\n\nThe scripts/context-checkpoint.sh script handles basic write/read/clear. For the full 5-section checkpoint, write the file directly — multiline content works better that way." }, { "title": "Post-Compaction Recovery", "body": "After compaction or /new:\n\nRead .context-checkpoint.md if it exists\nRead today's daily log if the workspace has one (e.g. memory/{today}.md)\nResume from the checkpoint's \"Next Steps\"\nDelete the checkpoint file after restoring context" }, { "title": "Proactive Warning Template", "body": "When context exceeds 65%, warn:\n\n⚠️ Context: {pct}% ({used}k/{total}k). Estimated runway: ~{remaining_calls}\ntool calls. {recommendation}\n\nRecommendations by level:\n\n65%: \"Spawning sub-agents for remaining tool-heavy work.\"\n75%: \"Recommend compacting soon. Writing checkpoint.\"\n85%: \"Context critical. Writing checkpoint now. Suggest /compact or /new.\"" }, { "title": "Session Profiling & Config Advice", "body": "After significant work (or on request), profile the current session and recommend config changes." }, { "title": "Step 1: Classify the Session Pattern", "body": "Run session_status. Count approximate tool calls and message exchanges. Classify:\n\nPatternSignatureExampleTool-heavyMost context from tool results, many exec/read/web callsAudits, migrations, test suites, debuggingConversationalMost context from messages, few tool callsPlanning, discussion, decisionsMixedRoughly even splitFeature builds (discuss → code → test → discuss)BurstyLong quiet periods with intense tool burstsMonitoring + incident response" }, { "title": "Step 2: Recommend Config", "body": "There are four settings that matter. When explaining them to the user, always describe what they do in practice, not just the setting name:\n\n1. When to compress the conversation (reserveTokensFloor)\nHow full the context gets before the agent summarises and compresses the history. A higher number means it compresses sooner — producing a shorter summary with more room left afterwards.\n\n30000 — waits until nearly full. Risk: huge summary, little room after.\n50000 — compresses at ~75% full. Good balance.\n60000 — compresses early at ~70%. Maximum breathing room.\n\n2. How quickly old tool output is cleared (pruning TTL)\nAfter you stop talking for this long, the agent clears old command outputs, file reads, and search results from memory. Shorter = more aggressive cleanup.\n\n5m — only clears after 5 minutes of silence. Rarely fires during active work.\n2m — clears after 2 minutes. Good for most workflows.\n1m — aggressive. Clears fast, but you might need to re-read files.\n\n3. How many recent exchanges are protected from cleanup (keepLastAssistants)\nWhen clearing old tool output, this many of your most recent back-and-forth exchanges are kept untouched.\n\n3 — keeps more history visible. Good for conversations.\n2 — moderate protection.\n1 — only the last exchange is safe. Most aggressive cleanup.\n\n4. Minimum size before tool output gets trimmed (minPrunableToolChars)\nOnly tool results larger than this (in characters) are eligible for trimming. Lower = more things get cleaned up.\n\n50000 (default) — only trims very large outputs (long file reads, huge command output).\n10000 — also trims medium outputs. Catches more.\n5000 — aggressive. Most tool results are eligible.\n\nRecommended combinations by work style:\n\nWork styleCompress atClear afterProtectTrim aboveTool-heavy (audits, tests, debugging)600001m110000Conversational (planning, discussion)300005m350000Mixed (code → test → discuss)500002m210000Bursty (monitoring + incidents)500002m110000\n\nAdditional tips:\n\nSessions with browser/canvas work: Ensure those tools are protected from cleanup in the config\nLong-running sessions (>2h): Use a higher compression trigger to survive multiple rounds" }, { "title": "Step 3: Report", "body": "Use a compact list format — tables render poorly on mobile and narrow chat windows. For each setting, show current vs recommended only if they differ. Skip settings that are already correct.\n\n📊 Current Session Profile: {pattern}\nContext: {pct}% ({used}k/{total}k) · Compressions: {c}\n\n✅ When to compress — {current_description}. Good for this work style.\n✅ Clear old output after — {current_description}. No change needed.\n⚠️ Protect last exchanges — currently {current}, recommend {recommended}. {why}\n✅ Trim output above — {current_description}. No change needed.\n\nEstimated runway: ~{time_or_calls} before next compression.\n\nLead with what's already right (builds confidence), then highlight what needs changing and why. Keep it short — the user wants a verdict, not a lecture.\n\nIf changes are recommended, tell the user everything up front before asking for approval:\n\nExact file being modified (full path — get from gateway config.get)\nExact changes — setting name, current value, new value\nWhat happens — gateway restart (~2-3 second pause, auto-reconnects)\nSafety net — backup taken first, rollback doc written to temp directory\n\nExample closing:\n\nOne change recommended:\n File: {config_path}\n Change: {setting_name}: {old_value} → {new_value}\n \nApplying means: I'll back up the config file first, write a rollback \ndoc to {temp_path}, then restart the OpenClaw gateway (~2-3 second \npause while it reloads). Want me to go ahead?\n\nFor multiple changes, list each one. Never summarise as \"4 changes\" — spell them out.\n\nNever ask \"want me to apply?\" without the user seeing the exact file, exact values, and exact consequences. The user decides with full information, not blind trust.\n\nIf the user agrees, follow the full procedure below." }, { "title": "Step 4: Learn Over Time", "body": "After giving advice, note the session pattern and outcome in the daily log (if the workspace keeps one). Over multiple sessions, patterns emerge — the user's typical work style becomes clear and default config can be permanently tuned." }, { "title": "Applying Config Changes — Mandatory Procedure", "body": "When recommending config changes, follow this exact sequence. No shortcuts." }, { "title": "1. Find the Config File", "body": "Run gateway config.get to get the config file path and current values. Do not assume the path — it varies by installation." }, { "title": "2. Backup First", "body": "cp .backup-$(date +%Y%m%d-%H%M%S)" }, { "title": "3. Write a Rollback Document", "body": "Write a rollback doc to a location the user can access (not the agent workspace — the user may not have access to it). Use a temp directory (/tmp/ on Linux/macOS, or the system temp dir). Include:\n\n# Context Config Rollback — {date}\n\n## What Changed\n| Setting | Before | After | File |\n|---------|--------|-------|------|\n| {setting} | {old} | {new} | {config_path} |\n\n## Backup Location\n{config_path}.backup-{timestamp}\n\n## How to Rollback\ncp {backup_path} {config_path}\n\n## How to Restart the Gateway\nDepends on local setup — check which applies:\n- CLI (most common): openclaw gateway restart\n- systemd service: sudo systemctl restart \n- Manual process: kill the gateway process, then: openclaw gateway start\n\n## How to Check Health\n- Process running: check for openclaw in process list\n- Gateway responding: curl http://localhost:/health\n- Logs: check system logs or terminal output depending on setup\n\n## What to Do If Gateway Won't Start\n1. Restore backup (cp command above)\n2. Restart gateway\n3. Check logs for config parse errors\n\nTell the user where this file is." }, { "title": "4. Explain to the User BEFORE Applying", "body": "Tell them:\n\nWhich file is being modified (full path — get it from gateway config.get)\nWhat values change (before → after table)\nWhat \"restart\" means — the OpenClaw gateway process restarts (not the machine, not any other service). Brief 2-3 second pause, then the session reconnects automatically.\nWhere the backup is (full path)\nWhere the rollback doc is (full path)\nHow to check if something goes wrong" }, { "title": "5. Apply with gateway config.patch", "body": "Use the gateway tool with action: config.patch. Include a clear note parameter — this message is delivered to the user after the gateway restarts." }, { "title": "6. Post-Restart Confirmation (MANDATORY)", "body": "After the gateway restarts and the session reconnects, immediately confirm to the user:\n\n✅ Gateway is back. Config changes applied successfully.\n\nWhat changed:\n- {setting}: {old} → {new} ({plain English explanation})\n- [etc.]\n\nRollback doc: {path}\nBackup: {path}\n\nEverything is working normally. Ready to continue.\n\nNever stay silent after a restart. The user needs to know:\n\nWe're back\nThe changes landed\nWhere to find the rollback doc\nThat we're ready to continue" }, { "title": "Reference Docs", "body": "For detailed config options and profiles: references/config-guide.md\nFor per-operation cost estimates: references/operation-costs.md" } ], "body": "Context Management\n\nPrevent context exhaustion, enforce spawn discipline, and make compaction survivable.\n\nCore Concepts\nFixed baseline: Typically 5-15% of context consumed before any conversation — system prompt, workspace files, skill descriptions, tool definitions. Varies by setup (more skills/files = higher baseline).\n60/40 rule: ~60% of consumed context is tool outputs, ~40% conversation. Tool outputs are the primary target for savings.\nCompaction is lossy: Summaries stack cumulatively. Each cycle raises the floor. After 3+ compactions, summaries alone can consume 30%+ of context.\nSub-agents are disposable context: A sub-agent can burn most of its context investigating something; only the summary (~500 tokens) enters main context.\n\nAll percentages are relative to the model's context window. Check session_status for actual window size and usage.\n\nProcedures\nWhen Context Pressure Rises\n\nAfter every tool-heavy operation (>5 tool calls), assess:\n\nRun session_status to check usage\nIf below 50%: continue normally\nIf 50-70%: spawn sub-agents for remaining tool-heavy work (>3 tool calls)\nIf 70-85%: spawn sub-agents for ANY tool work (>1 tool call). Warn user.\nIf above 85%: write checkpoint (see below), suggest /compact or /new\n\"What's Eating My Context?\" — Estimation Method\n\nCannot get exact per-component breakdown. Estimate:\n\nFixed baseline: ~5-15% (system prompt + workspace files + skills + tools)\nPer user message: ~100-500 tokens each\nPer assistant response: ~200-1000 tokens each\nPer tool call result: ~500-5000 tokens each (exec/read heavy, search light)\nCompaction summaries: ~2000-5000 tokens each (cumulative!)\n\n\nCount messages and tool calls in recent history, multiply by midpoint estimates. Report as ranges, not false precision. For per-operation cost detail, read references/operation-costs.md.\n\nSpawn Policy\n\nIf .context-policy.yml exists in workspace root, use it as guidance for spawn thresholds and task categories. Otherwise use these defaults:\n\nAlways spawn (regardless of context level):\n\nTest suites (>3 tests)\nMulti-file audits (>5 files)\nBuild/deploy pipelines\nResearch tasks (web search + analysis)\nBulk file operations\n\nNever spawn (keep in main session):\n\nSingle commands\nConversations / discussions\nQuick edits (1-3 files)\nStatus checks\nTasks requiring user input mid-execution\n\nContext-dependent (spawn when context exceeds threshold):\n\nAbove 50%: spawn if task involves >5 tool calls\nAbove 70%: spawn if task involves >2 tool calls\n\nWhen spawning, write detailed task descriptions. Sub-agents have no conversation context — they only know what the task field tells them.\n\nPre-Compaction Checkpoint\n\nBefore compaction or /new, write .context-checkpoint.md in the workspace root (the agent reads this post-compaction):\n\n# Context Checkpoint — {date} {time}\n\n## Active Task\n{what you were doing}\n\n## Key State\n{bullet list of current state — what's done, what's in progress}\n\n## Decisions Made This Session\n{numbered list of decisions with rationale}\n\n## Files Changed\n{list of files modified this session}\n\n## Next Steps\n{what to do after resuming}\n\n\nThis file survives compaction. On session start or post-compaction, check for it and use it to restore context. Delete after consuming.\n\nCoordination with OpenClaw memoryFlush: OpenClaw may fire its own pre-compaction flush (writing to daily log). The checkpoint is complementary — the flush saves to the daily log, the checkpoint saves structured resume state. Both should exist. If the memoryFlush fires first, compaction may already be in progress. For critical sessions, write checkpoints proactively at 75%, don't wait for 85%.\n\nThe scripts/context-checkpoint.sh script handles basic write/read/clear. For the full 5-section checkpoint, write the file directly — multiline content works better that way.\n\nPost-Compaction Recovery\n\nAfter compaction or /new:\n\nRead .context-checkpoint.md if it exists\nRead today's daily log if the workspace has one (e.g. memory/{today}.md)\nResume from the checkpoint's \"Next Steps\"\nDelete the checkpoint file after restoring context\nProactive Warning Template\n\nWhen context exceeds 65%, warn:\n\n⚠️ Context: {pct}% ({used}k/{total}k). Estimated runway: ~{remaining_calls}\ntool calls. {recommendation}\n\n\nRecommendations by level:\n\n65%: \"Spawning sub-agents for remaining tool-heavy work.\"\n75%: \"Recommend compacting soon. Writing checkpoint.\"\n85%: \"Context critical. Writing checkpoint now. Suggest /compact or /new.\"\nSession Profiling & Config Advice\n\nAfter significant work (or on request), profile the current session and recommend config changes.\n\nStep 1: Classify the Session Pattern\n\nRun session_status. Count approximate tool calls and message exchanges. Classify:\n\nPattern\tSignature\tExample\nTool-heavy\tMost context from tool results, many exec/read/web calls\tAudits, migrations, test suites, debugging\nConversational\tMost context from messages, few tool calls\tPlanning, discussion, decisions\nMixed\tRoughly even split\tFeature builds (discuss → code → test → discuss)\nBursty\tLong quiet periods with intense tool bursts\tMonitoring + incident response\nStep 2: Recommend Config\n\nThere are four settings that matter. When explaining them to the user, always describe what they do in practice, not just the setting name:\n\n1. When to compress the conversation (reserveTokensFloor) How full the context gets before the agent summarises and compresses the history. A higher number means it compresses sooner — producing a shorter summary with more room left afterwards.\n\n30000 — waits until nearly full. Risk: huge summary, little room after.\n50000 — compresses at ~75% full. Good balance.\n60000 — compresses early at ~70%. Maximum breathing room.\n\n2. How quickly old tool output is cleared (pruning TTL) After you stop talking for this long, the agent clears old command outputs, file reads, and search results from memory. Shorter = more aggressive cleanup.\n\n5m — only clears after 5 minutes of silence. Rarely fires during active work.\n2m — clears after 2 minutes. Good for most workflows.\n1m — aggressive. Clears fast, but you might need to re-read files.\n\n3. How many recent exchanges are protected from cleanup (keepLastAssistants) When clearing old tool output, this many of your most recent back-and-forth exchanges are kept untouched.\n\n3 — keeps more history visible. Good for conversations.\n2 — moderate protection.\n1 — only the last exchange is safe. Most aggressive cleanup.\n\n4. Minimum size before tool output gets trimmed (minPrunableToolChars) Only tool results larger than this (in characters) are eligible for trimming. Lower = more things get cleaned up.\n\n50000 (default) — only trims very large outputs (long file reads, huge command output).\n10000 — also trims medium outputs. Catches more.\n5000 — aggressive. Most tool results are eligible.\n\nRecommended combinations by work style:\n\nWork style\tCompress at\tClear after\tProtect\tTrim above\nTool-heavy (audits, tests, debugging)\t60000\t1m\t1\t10000\nConversational (planning, discussion)\t30000\t5m\t3\t50000\nMixed (code → test → discuss)\t50000\t2m\t2\t10000\nBursty (monitoring + incidents)\t50000\t2m\t1\t10000\n\nAdditional tips:\n\nSessions with browser/canvas work: Ensure those tools are protected from cleanup in the config\nLong-running sessions (>2h): Use a higher compression trigger to survive multiple rounds\nStep 3: Report\n\nUse a compact list format — tables render poorly on mobile and narrow chat windows. For each setting, show current vs recommended only if they differ. Skip settings that are already correct.\n\n📊 Current Session Profile: {pattern}\nContext: {pct}% ({used}k/{total}k) · Compressions: {c}\n\n✅ When to compress — {current_description}. Good for this work style.\n✅ Clear old output after — {current_description}. No change needed.\n⚠️ Protect last exchanges — currently {current}, recommend {recommended}. {why}\n✅ Trim output above — {current_description}. No change needed.\n\nEstimated runway: ~{time_or_calls} before next compression.\n\n\nLead with what's already right (builds confidence), then highlight what needs changing and why. Keep it short — the user wants a verdict, not a lecture.\n\nIf changes are recommended, tell the user everything up front before asking for approval:\n\nExact file being modified (full path — get from gateway config.get)\nExact changes — setting name, current value, new value\nWhat happens — gateway restart (~2-3 second pause, auto-reconnects)\nSafety net — backup taken first, rollback doc written to temp directory\n\nExample closing:\n\nOne change recommended:\n File: {config_path}\n Change: {setting_name}: {old_value} → {new_value}\n \nApplying means: I'll back up the config file first, write a rollback \ndoc to {temp_path}, then restart the OpenClaw gateway (~2-3 second \npause while it reloads). Want me to go ahead?\n\n\nFor multiple changes, list each one. Never summarise as \"4 changes\" — spell them out.\n\nNever ask \"want me to apply?\" without the user seeing the exact file, exact values, and exact consequences. The user decides with full information, not blind trust.\n\nIf the user agrees, follow the full procedure below.\n\nStep 4: Learn Over Time\n\nAfter giving advice, note the session pattern and outcome in the daily log (if the workspace keeps one). Over multiple sessions, patterns emerge — the user's typical work style becomes clear and default config can be permanently tuned.\n\nApplying Config Changes — Mandatory Procedure\n\nWhen recommending config changes, follow this exact sequence. No shortcuts.\n\n1. Find the Config File\n\nRun gateway config.get to get the config file path and current values. Do not assume the path — it varies by installation.\n\n2. Backup First\ncp .backup-$(date +%Y%m%d-%H%M%S)\n\n3. Write a Rollback Document\n\nWrite a rollback doc to a location the user can access (not the agent workspace — the user may not have access to it). Use a temp directory (/tmp/ on Linux/macOS, or the system temp dir). Include:\n\n# Context Config Rollback — {date}\n\n## What Changed\n| Setting | Before | After | File |\n|---------|--------|-------|------|\n| {setting} | {old} | {new} | {config_path} |\n\n## Backup Location\n{config_path}.backup-{timestamp}\n\n## How to Rollback\ncp {backup_path} {config_path}\n\n## How to Restart the Gateway\nDepends on local setup — check which applies:\n- CLI (most common): openclaw gateway restart\n- systemd service: sudo systemctl restart \n- Manual process: kill the gateway process, then: openclaw gateway start\n\n## How to Check Health\n- Process running: check for openclaw in process list\n- Gateway responding: curl http://localhost:/health\n- Logs: check system logs or terminal output depending on setup\n\n## What to Do If Gateway Won't Start\n1. Restore backup (cp command above)\n2. Restart gateway\n3. Check logs for config parse errors\n\n\nTell the user where this file is.\n\n4. Explain to the User BEFORE Applying\n\nTell them:\n\nWhich file is being modified (full path — get it from gateway config.get)\nWhat values change (before → after table)\nWhat \"restart\" means — the OpenClaw gateway process restarts (not the machine, not any other service). Brief 2-3 second pause, then the session reconnects automatically.\nWhere the backup is (full path)\nWhere the rollback doc is (full path)\nHow to check if something goes wrong\n5. Apply with gateway config.patch\n\nUse the gateway tool with action: config.patch. Include a clear note parameter — this message is delivered to the user after the gateway restarts.\n\n6. Post-Restart Confirmation (MANDATORY)\n\nAfter the gateway restarts and the session reconnects, immediately confirm to the user:\n\n✅ Gateway is back. Config changes applied successfully.\n\nWhat changed:\n- {setting}: {old} → {new} ({plain English explanation})\n- [etc.]\n\nRollback doc: {path}\nBackup: {path}\n\nEverything is working normally. Ready to continue.\n\n\nNever stay silent after a restart. The user needs to know:\n\nWe're back\nThe changes landed\nWhere to find the rollback doc\nThat we're ready to continue\nReference Docs\n\nFor detailed config options and profiles: references/config-guide.md For per-operation cost estimates: references/operation-costs.md" }, "trust": { "sourceLabel": "tencent", "provenanceUrl": "https://clawhub.ai/marcus-daemon/context-management", "publisherUrl": "https://clawhub.ai/marcus-daemon/context-management", "owner": "marcus-daemon", "version": "1.0.0", "license": null, "verificationStatus": "Indexed source record" }, "links": { "detailUrl": "https://openagent3.xyz/skills/context-management", "downloadUrl": "https://openagent3.xyz/downloads/context-management", "agentUrl": "https://openagent3.xyz/skills/context-management/agent", "manifestUrl": "https://openagent3.xyz/skills/context-management/agent.json", "briefUrl": "https://openagent3.xyz/skills/context-management/agent.md" } }