shared-memory-governor
PassAudited by ClawScan on May 10, 2026.
Overview
This instruction-only skill is openly about creating a reviewable shared-memory layer for agents; it shows no malicious behavior, but users should understand that selected memory can persist and be reused across agents.
Install this only if you want a persistent shared-memory layer for multiple agents. Before use, choose the shared root deliberately, review which MEMORY.md or USER.md files can be promoted, keep secrets out, confirm AGENTS.md/SHARED_ATTACH.md changes, and leave recurring shared scans or maintenance disabled unless you intentionally enable them.
Findings (3)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
Approved memories may be reused by multiple agents in later sessions, so a bad or sensitive entry could influence future behavior.
The skill intentionally stores durable context that multiple agents may later read. This is clearly disclosed and central to the purpose, but persistent shared memory can affect future sessions if incorrect, stale, or over-shared.
Add a separate, reviewable shared-memory layer for durable user preferences, shared rules, and cross-agent facts.
Review shared-user.md, shared-memory.md, shared-rules.md, and sync logs regularly; do not approve secrets or private agent identity context for sharing.
Attached agents may automatically load shared memory on future starts, which can change their context until the attachment is removed.
Attachment can add persistent startup behavior so future agent sessions read the shared-memory layer. The behavior is documented and includes detach rules, but it is still persistent agent-control context.
If local `SHARED_ATTACH.md` is present, read it as part of session startup. Then read the shared memory files exactly as instructed by `SHARED_ATTACH.md`.
After attaching or detaching an agent, inspect AGENTS.md and SHARED_ATTACH.md to confirm the startup guidance matches your intent.
A bad shared-memory entry could influence multiple agents or subagents that read from the same shared layer.
The example configuration allows subagents to read shared memory, so a mistaken shared-memory entry could propagate across more than one agent. Direct subagent writes are disabled, which mitigates the risk.
"includeSubagents": true, "subagentsReadShared": true, "subagentsWriteShared": false, "subagentContributionMode": "relay-to-maintainer"
Keep subagent writes disabled unless truly needed, and disable subagent shared-memory reading if you do not want context to propagate to subagents.