Shared Memory Governor

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. 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

1. 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. 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:

CODEBLOCK0

File roles

• - shared-user.md → stable user preferences, habits, and constraints
• INLINECODE1 → durable facts reusable across agents
• INLINECODE2 → governance rules for the shared-memory system
• INLINECODE3 → operational logs for review and traceability
• INLINECODE4 → archived local shared-memory guidance after detach

For detailed file-boundary examples, read:

• - INLINECODE5

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:

• - INLINECODE6

For config details, read:

• - INLINECODE7

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:

• - INLINECODE8
• INLINECODE9

For startup guidance placement and cleanup rules, read:

• - INLINECODE10

Important:

• - register does not automatically mean INLINECODE12
• 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:

• - INLINECODE13
• INLINECODE14
• INLINECODE15
• INLINECODE16

For status and reporting fields, read:

• - INLINECODE17

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:

• - INLINECODE18

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:

• - INLINECODE19

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:

• - INLINECODE20

For reporting fields and maintenance review structure, read:

• - INLINECODE21
• INLINECODE22

6) Repair, detach, or remove an agent

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

Use:

• - INLINECODE23
• INLINECODE24
• INLINECODE25

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:

• - INLINECODE26

Reference map

Read these files only when needed:

• - INLINECODE27

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

• - INLINECODE28

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

• - INLINECODE29

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

• - INLINECODE30

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

Commands

V1 supports:

• - INLINECODE31
• INLINECODE32
• INLINECODE33
• INLINECODE34
• INLINECODE35
• INLINECODE36
• INLINECODE37
• INLINECODE38
• INLINECODE39
• INLINECODE40
• INLINECODE41
• INLINECODE42
• INLINECODE43
• INLINECODE44
• INLINECODE45

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