shared-memory-governor

Govern a file-based shared-memory layer for OpenClaw multi-agent and subagent systems. Preserve each agent’s private memory while adding a separate, reviewab...

Security Scan

The skill is an instruction-only governance document for a shared, file-based memory layer; its requested footprint (no installs, no env vars, no credentials) matches the described purpose and I found no signs of incoherent or hidden behavior.

Purpose & Capability

Name/description match the content: all files are configuration and governance references for a file-based shared-memory layer. The skill does not request unrelated credentials, binaries, or external services that would be inconsistent with a local shared-file governance tool.

Instruction Scope

SKILL.md and references clearly constrain behavior (operate only inside user-designated workspace paths; never read credentials/secrets; keep shared memory supplemental). The only notable point is that the documented default config path resolves to /root/.openclaw/shared-memory/shared-memory.config.json (explicit in config-reference.md), so users should confirm that the default location matches their intended workspace; otherwise, commands may operate on the workspace under that path. Overall the instructions are specific and scoped to the stated purpose.

Install Mechanism

Instruction-only skill with no install spec, no binaries, and no archives to download. This is the lowest-risk install profile and is proportional to the described governance role.

Credentials

No environment variables, no credentials, and no required config paths beyond the documented workspace-shared path. The included example config explicitly disables shared recurring schedules by default (sharedScan/sharedMaintenance false) and sets sharing flags to disallow secrets and assistant identity; these align with the stated privacy-first goals.

Persistence & Privilege

Skill does not request always:true and does not claim autonomous persistent background execution. Example config contains schedule entries (privateMaintenance enabled, shared schedules disabled) — schedule activation would be a local config choice and is documented; the skill itself does not install persistent agents or services.

Assessment

This is an instruction-only governance skill (no code, no installs, no credentials requested) and appears coherent with its purpose. Before enabling it in your workspace: 1) confirm the intended sharedRoot path — the reference defaults to /root/.openclaw/shared-memory, so change it if your workspace is elsewhere; 2) review schedule settings in the example config (privateMaintenance is enabled in the example) and disable any recurring tasks you do not want running; 3) ensure local SHARED_ATTACH.md and AGENTS.md guidance are accurate for each agent so the read/attach rules are enforced; and 4) remember this is documentation for operator behavior — the safety guarantees rely on the agent implementation following these rules, so audit any runtime that will implement these steps if you need stronger enforcement (e.g., code-level guards or OS permissions).

Preserve each agent’s private long-term memory.

Add a separate, reviewable shared-memory layer for durable user preferences, shared rules, and cross-agent facts.

Keep assistant-specific identity context private.

What this skill is for

Use this skill to govern a shared-memory layer across multiple agents while preserving each agent’s private memory system.

This skill helps define:

• what kinds of information may be shared
• what kinds of information must remain private
• how shared-memory files should be organized
• how attached agents should read shared memory in a safe order
• how shared-memory updates should remain reviewable and reversible

This skill is for workspace-scoped shared-memory design and maintenance. It is not a credential tool, not a hidden prompt tool, and not a system-level persistence mechanism.

Safety boundaries

Follow these boundaries at all times:

• Operate only within user-designated workspace paths
• Process only explicitly approved memory files
• Treat shared memory as supplemental context, not identity-defining context
• Keep assistant-specific identity context private
• Keep shared-memory updates reviewable and reversible
• Keep recurring schedules disabled by default unless the user explicitly enables them

Never:

• read credentials, SSH keys, browser sessions, or unrelated local files
• collect plaintext secrets into shared memory
• alter hidden system prompts or hidden runtime policy layers
• treat assistant identity files as shared-memory sources in v1
• silently enable recurring background schedules

Core model

Use a two-layer long-term memory model:

1. Private memory layer

   • Each agent keeps its own curated memory notes
   • Each agent keeps its own daily memory files
   • Each agent keeps its own local assistant-specific context

2. Shared memory layer

   • Store shared files under the shared root directory
   • Use this layer for stable user preferences, shared rules, and durable cross-agent facts
   • Treat this layer as part of the long-term memory workflow
   • Do not use this layer for assistant-specific identity context

Core principles

Follow these rules at all times:

1. Preserve private memory systems
2. Share user-level and cross-agent durable context, not assistant-specific identity context
3. Read private memory first, then shared memory
4. Treat shared memory as supplemental background
5. Never let shared memory override assistant-specific identity context or private identity guidance
6. Do not auto-delete private entries after promotion to shared memory
7. Require explicit local guidance for participating agents
8. Keep assistant identity context private in v1
9. Prefer conservative promotion decisions

Shared memory structure

Use the shared root with this default structure:

<sharedRoot>/
├── shared-user.md
├── shared-memory.md
├── shared-rules.md
├── shared-sync-log/
│   ├── YYYY-MM-DD_HHMM_scan.md
│   └── YYYY-MM-DD_HHMM_maintenance.md
└── archived/
    └── <agent>/

File roles

• shared-user.md → stable user preferences, habits, and constraints
• shared-memory.md → durable facts reusable across agents
• shared-rules.md → governance rules for the shared-memory system
• shared-sync-log/ → operational logs for review and traceability
• archived/<agent>/ → archived local shared-memory guidance after detach

For detailed file-boundary examples, read:

• references/shared-promotion-rules.md

High-level workflows

1) Initialize the shared-memory system

Use when the shared layer does not exist yet.

Goal:

• create the shared root structure
• create base shared files
• create the default config
• prepare shared scan and shared maintenance schedules in a disabled-by-default state

Use:

• init

For config details, read:

• references/config-reference.md

2) Register and attach an agent

Use when an agent should participate in the shared-memory system.

Goal:

• add the agent to the participant set
• create or update local shared-memory guidance
• make the shared read path explicit and reviewable

Use:

• register <agent>
• attach <agent>

For startup guidance placement and cleanup rules, read:

• references/startup-guidance-rules.md

Important:

• register does not automatically mean attach
• updating local guidance files does not retroactively change what an already-running session has loaded

3) Review status and local readiness

Use when checking whether the shared-memory system is set up correctly.

Goal:

• inspect global shared-memory status
• review whether each attached agent has complete local guidance
• review schedule consistency against config

Use:

• show-status
• review-attachments
• show-config
• validate-config

For status and reporting fields, read:

• references/status-review-fields.md

4) Run shared promotion

Use when updating the shared layer from approved upstream memory sources.

Goal:

• review approved local memory sources
• identify cautiously promotable shared candidates
• update shared-memory files conservatively
• record a scan log and summary

Use:

• run-shared-scan

Default rule in v1:

• shared promotion should be conservative
• single-agent local items should be skipped by default unless they have explicit shared-scope justification

For promotion decisions and target-file boundaries, read:

• references/shared-promotion-rules.md

5) Run shared maintenance

Use when reviewing and refining the shared layer itself.

Goal:

• deduplicate shared entries
• merge or refine overlapping entries when appropriate
• prune outdated shared content
• update governance notes when needed

Use:

• run-shared-maintenance

For reporting fields and maintenance review structure, read:

• references/status-review-fields.md
• references/config-reference.md

6) Repair, detach, or remove an agent

Use when local shared-memory guidance is incomplete, stale, or no longer needed.

Use:

• repair-attachment <agent>
• detach <agent>
• unregister <agent>

Rules:

• detach should remove local shared-memory guidance, not private memory
• unregister should normally happen after detach when local guidance is still active

For startup guidance repair and detach cleanup rules, read:

• references/startup-guidance-rules.md

Reference map

Read these files only when needed:

• references/startup-guidance-rules.md

  • local startup guidance placement
  • fallback placement
  • attach success criteria
  • detach cleanup behavior

• references/shared-promotion-rules.md

  • shared-scope validation
  • promotion categories
  • target-file boundaries
  • promotion report fields

• references/status-review-fields.md

  • status display fields
  • attachment review fields
  • schedule consistency outcomes
  • maintenance report section order

• references/config-reference.md

  • config schema
  • field meanings
  • config-related command behavior
  • schedule/config consistency rules

Commands

V1 supports:

• init
• show-config
• validate-config
• update-config
• register <agent>
• unregister <agent>
• attach <agent>
• detach <agent>
• repair-attachment <agent>
• run-shared-scan
• run-shared-maintenance
• show-status
• review-attachments
• show-sync-logs
• prune-sync-logs

Config-related commands may support explicit config paths.

Default operating stance

Keep this skill:

• low-intrusion
• explicit
• auditable
• configuration-driven
• strict about identity isolation
• conservative about write authority
• centered on governance rather than hidden magic