Skip to content
Data
Skill

/slm-scope

Controls memory visibility across profiles — personal (private, default), shared (selected profiles), or global (all profiles on this machine). Default is always personal. Only change scope when the user explicitly asks to share a memory across workspaces. Works with both

From plugin
superlocalmemory
27016 skills4 agents1 command1 MCP

Claude Code

$ npx -y skills add qualixar/superlocalmemory --skill slm-scope --agent claude-code

SKILL.md

slm-scope.SKILL.md
name: slm-scope
description: Controls memory visibility across profiles — personal (private, default), shared (selected profiles), or global (all profiles on this machine). Default is always personal. Only change scope when the user explicitly asks to share a memory across workspaces. Works with both remember (write scope) and recall (read scope flags).
when_to_use: |
  - "Share this memory with the team profile"
  - "Store this globally so all my agents can see it"
  - "Recall anything shared from the work profile"
  - "Can other agents on this machine see my memories?"
  - User explicitly asks to cross-profile share a fact or see shared facts
  - Enterprise setup where multiple profiles collaborate
allowed-tools: remember, recall, search, list_recent, Bash(slm:*)

slm-scope — Memory Scope and Sharing Model

SuperLocalMemory is profile-isolated by default. Every profile is a fully independent memory namespace. The scope model adds controlled, opt-in sharing between profiles on the same machine — it is never active unless you explicitly set it.

---

The Three Scopes

| Scope | Visibility | When to use | |-------|-----------|-------------| | `personal` | Active profile only | Default — all facts. Never set explicitly. | | `shared` | Active profile + `shared_with` profiles | Team handoffs, shared project context | | `global` | Every profile on this machine | Machine-wide conventions, org-wide rules |

**The default is always `personal`.** A fact stored without a `scope` argument is private to the profile that stored it. Recall without scope flags returns only personal facts. This is identical to single-profile SLM.

---

Opt-in is mandatory

Never set `scope="shared"` or `scope="global"` (or the recall equivalents `include_shared`, `include_global`) unless the user explicitly asks you to share or read across profiles. This is a hard rule — scope expansion is an action with team-wide or machine-wide impact, and it must always be user-initiated.

---

Writing a shared or global fact

share with specific profiles

remember(
  content="API gateway rate limit is 1000 req/min per client",
  tags="api,limits,ops",
  project="platform",
  importance=8,
  session_id="<sid>",
  scope="shared",
  shared_with="devops-profile,backend-profile",
)

`shared_with` is a comma-separated list of profile IDs that should be able to recall this fact. Use `slm status` to see the current profile name — that is the `profile_id` to supply.

share with all profiles on the machine

remember(
  content="All services must enforce TLS 1.3 minimum",
  tags="security,tls,global",
  project="infra",
  importance=9,
  session_id="<sid>",
  scope="global",
)

`scope="global"` makes the fact visible to every profile on this machine. Use this only for machine-wide conventions (security rules, org-wide constraints).

---

Reading shared or global facts

By default, `recall` returns only the active profile's personal facts. To surface shared and global facts, pass the opt-in flags:

recall(
  query="rate limiting rules",
  limit=20,
  include_global=True,   # include global-scope facts
  include_shared=True,   # include facts shared with this profile
  session_id="<sid>",
)

You can opt in to either or both flags independently. Only the active profile's permitted shared facts are returned — you cannot read another profile's personal facts.

CLI equivalents

# Recall with global facts included
slm recall "rate limiting rules" --include-global

# Recall with shared facts included
slm recall "rate limiting rules" --include-shared

# Both
slm recall "rate limiting rules" --include-global --include-shared

# Store a global fact
slm remember "TLS 1.3 minimum" --scope global

# Store a shared fact (shared-with is a comma-separated list of profile IDs)
slm remember "API rate limit 1000/min" --scope shared --shared-with devops,backend

CLI flags: `--include-global` / `--no-global`, `--include-shared` / `--no-shared` on `slm recall`; `--scope personal|shared|global` and `--shared-with <profile-ids>` on `slm remember`. Leaving a flag unset uses the configured default.

---

Configuring scope defaults

The defaults live in the `scope` section of the mode config files (`mode_a.json`, `mode_b.json`, `mode_c.json`, and the active `config.json`). To make a profile's recalls always include global facts without passing a flag each time:

{
  "scope": {
    "default_scope": "personal",
    "recall_include_global": true,
    "recall_include_shared": false
  }
}

Omit the section, or any field, to keep the safe defaults (`personal`, `false`, `false`). An invalid `default_scope` is ignored with a warning. Changing the default requires editing the config directly — this is an admin-level operation, and an agent must not do it on its own.

---

Enterprise governance

In a workspace with roles (company mode, see `slm-governance`):

  • **Viewers** cannot write at all, whatever `scope` says.
  • **Members and admins** can write `shared` and `global` facts: both hold the

share permission. Deleting needs the delete permission, which only admins hold.

  • Explicit `include_global=True` / `include_shared=True` on `recall` are quietly

turned off while the recall policy forbids cross-profile reads, which is the default in company mode. If an opt-in recall returns only personal facts in a governed workspace, that is the policy working, not a bug; do not try to work around it.

---

Scope deletion and retention

A `scope="global"` fact deleted by one profile is deleted for all profiles. A `scope="shared"` fact is deleted from all profiles that had access to it. Use `slm forget "<query>" --dry-run` before any deletion involving shared facts to review the impact. See `slm-remember` for the full deletion discipline.

---

Related skills

  • `slm-remember` — full fact storage reference including scope parameters
  • `slm-recall` — full retrieval reference including include_
Read more
@qualixar
Ships withsuperlocalmemory

Open-source governed, local-first memory control plane for AI agents and teams. arXiv:2608.08253

27016 skills4 agents1 MCP
Get the whole plugin

Stars on GitHub

Momentum

stars in total
270
Star history of qualixar/superlocalmemory on GitHub, a chart by star-history.com

Other skills on superlocalmemory.

slm-cache

slm-cache

KV cache for repeated reads — call slm_cache_get(key) first; on a miss do the expensive operation then slm_cache_set(key, value,…

slm-compress

slm-compress

Compress large text, tool output, or transcripts to reduce context-window usage while keeping the full 1M window intact — call…

slm-graph

slm-graph

Index and query a codebase as a structural graph — build the code graph, trace blast radius of a change, find…

More skills from other plugins.

context-loader
Auto-invoked

context-loader

Search memories from earlier Pi sessions in this repository. Use it when earlier work may already explain the code, error,…

mem07d69k
@mem0ai@mem0aiInstall Skill
analyzing-ai-citations

analyzing-ai-citations

Answer AI citation and answer engine optimization (AEO) questions in PostHog: whether AI answer engines (ChatGPT, Claude, and an…

posthog2w41k
@posthog@posthogInstall Skill

Questions about slm-scope.

Which coding agents can use slm-scope?
slm-scope installs in Claude Code, Codex, Cursor, Gemini CLI, GitHub Copilot, OpenCode and Windsurf with the skills CLI, using each agent's flag shown on this page. Flowy's auto-invocation, which fires a skill when your prompt matches, runs in Claude Code only.