/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
$ npx -y skills add qualixar/superlocalmemory --skill slm-scope --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/slm-scope
Context preview
The summary Claude sees to decide when to auto-load this skill.
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
SKILL.md
slm-scope.SKILL.mdname: 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-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 verified in source: `--include-global` / `--no-global`, `--include-shared` / `--no-shared`, `--scope personal|shared|global`, `--shared-with <profile-ids>`.
---
Configuring scope defaults
Per-profile defaults live in `mode_a/b/c.json` configuration. To make a profile always include global facts without passing flags each time:
{
"recall": {
"include_global": true,
"include_shared": false
}
}Changing the default requires editing the profile config directly — this is an admin-level operation.
---
Enterprise governance
In a governed workspace (admin/member/viewer roles), scope expansion may be restricted:
- **Viewers** cannot write `scope="global"` facts — their writes are always `personal`.
- **Members** can write `scope="shared"` with profiles in their access list.
- **Admins** can write `scope="global"` unrestricted.
See `slm-governance` for the full enterprise behavior model.
---
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_global/include_shared
- `slm-profile` — what a profile is and how to switch between them
- `slm-governance` — enterprise role restrictions on scope
---
*SuperLocalMemory v4.0.0 · Qualixar · AGPL-3.0-or-later*
Read more
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-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 verified in source: `--include-global` / `--no-global`, `--include-shared` / `--no-shared`, `--scope personal|shared|global`, `--shared-with <profile-ids>`.
---
Configuring scope defaults
Per-profile defaults live in `mode_a/b/c.json` configuration. To make a profile always include global facts without passing flags each time:
{
"recall": {
"include_global": true,
"include_shared": false
}
}Changing the default requires editing the profile config directly — this is an admin-level operation.
---
Enterprise governance
In a governed workspace (admin/member/viewer roles), scope expansion may be restricted:
- **Viewers** cannot write `scope="global"` facts — their writes are always `personal`.
- **Members** can write `scope="shared"` with profiles in their access list.
- **Admins** can write `scope="global"` unrestricted.
See `slm-governance` for the full enterprise behavior model.
---
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_global/include_shared
- `slm-profile` — what a profile is and how to switch between them
- `slm-governance` — enterprise role restrictions on scope
---
*SuperLocalMemory v4.0.0 · Qualixar · AGPL-3.0-or-later*
World's first local-only AI memory to break 74% retrieval and 60% zero-LLM on LoCoMo. No cloud, no APIs, no data leaves your machine. Additionally, mode C (LLM/Cloud) - 87.7% LoCoMo. Research-backed. arXiv: 2603.14588
Repo: qualixar/superlocalmemory
Other skills on superlocalmemory.
- /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, ttl_seconds) to store it; on a hit use the returned value directly; always fail-open (hit:false on any error, never raises); saves tokens when the
Open skill - /slm-compress
Compress large text, tool output, or transcripts to reduce context-window usage while keeping the full 1M window intact — call slm_compress(content, mode, reversible, ttl_seconds) to shrink content; if the result is lossy a ccr_id is returned so you can call slm_retrieve(ccr_id)
Open skill - /slm-governance
Enterprise compliance and governed workspace behavior for SuperLocalMemory. Covers role-based access (admin/member/viewer), retention policies, audit trail, GDPR data export/erase, and how agents must behave when operating under workspace governance. Requires power MCP profile
Open skill - /slm-graph
Index and query a codebase as a structural graph — build the code graph, trace blast radius of a change, find callers/callees/inheritors, semantic code search by meaning, assemble PR review context, and detect what changed since last index. Use when the user asks how code
Open skill - /slm-loop
Run gate-verified bounded loops with SuperLocalMemory as the durable ledger. Use when a task has a checkable acceptance condition (tests, schema, lint, reconciliation) and you must iterate until an INDEPENDENT gate passes — never stopping just because the agent believes it is
Open skill - /slm-mesh
Cross-session peer coordination via the SLM mesh network. Lets multiple AI agent sessions on the same machine discover each other, send messages, share lightweight state, and lock files to avoid conflicts. Requires full, power, or mesh MCP profile. All 8 tools are MCP-only —
Open skill

