Memory System Sidecar

Operate, verify, rebuild, and debug the implemented MemoryLab long-term memory sidecar feeding active task and live context files.

Security Scan

The skill's instructions, scripts, and requested resources align with its stated purpose of operating and debugging an in-repo memory sidecar; there are no unexplained external dependencies, credential requests, or suspicious endpoints.

Purpose & Capability

The skill is declared as an instruction-only operator for the repo's memory sidecar and all actions map to local repo operations (refresh, verify, rebuild). Small mismatch: the runtime commands invoke python3 and repo wrapper scripts but the registry metadata lists no required binaries; this is a minor documentation gap (python3 is implicitly required).

Instruction Scope

SKILL.md directs the agent to run three repository wrapper scripts and to inspect files under memory/, memory-system/, history/, and related docs. The instructions do not ask the agent to read or exfiltrate unrelated system files or environment variables and they point only to project-local artifacts.

Install Mechanism

There is no install spec (instruction-only) and the included shell scripts are small wrappers around repo-local Python tools. No downloads, external package installs, or archive extraction are present.

Credentials

The skill declares no required env vars, secrets, or config paths and the instructions do not reference credentials. This is proportional to the stated purpose. Note that runtime code (tests/eval/build_index) could itself access environment variables — review those files if you need to ensure no secrets are used.

Persistence & Privilege

always is false and the skill does not request modifications to other skills or system-wide config. It runs only when invoked and does not request permanent presence or elevated platform privileges.

Assessment

This skill appears coherent and limited to running repository-local refresh/verify/rebuild workflows. Before running it: (1) ensure you trust the repository code because the scripts invoke python3 unit tests and eval scripts which can execute arbitrary Python in the repo; (2) confirm python3 is available (registry metadata omitted this requirement); (3) inspect the referenced Python files (memory-system/ingest/build_index.py, memory-system/eval/run_eval.py, and the test modules) if you will run this in an environment with sensitive data or credentials — those files could make network calls or read env vars even though the skill doesn't request secrets. If you want tighter safety, run the scripts in an isolated environment (container/VM) or review the code prior to execution.

Use this skill for the implemented MemoryLab memory system, not just abstract planning.

The system boundary is:

• Context manager = hot-path compactor
• Memory sidecar = long-term extraction, indexing, retrieval, consolidation
• Bridge = feeds retrieved memory back into ACTIVE_TASK_STATE / LIVE_CONTEXT_PACKET without treating them as source of truth

Quick workflow

Choose the smallest workflow that matches the task.

1. Refresh live context + sidecar from a real session

Use when the user says things like:

• "refresh memory"
• "rebuild context from the laptop session"
• "update the live packet from the current session"

Run:

./skills/memory-system-sidecar/scripts/refresh_memory_system.sh

This wraps the repo’s standard end-to-end refresh path.

2. Verify the memory system still passes

Use when the user asks:

• "is the memory system working?"
• "does milestone 5 still hold?"
• "run the checks"

Run:

./skills/memory-system-sidecar/scripts/verify_memory_system.sh

This runs the main unit tests plus the eval harness.

3. Rebuild indexes only

Use when eval/retrieval drifts or docs mention stale-index behavior.

Run:

./skills/memory-system-sidecar/scripts/rebuild_memory_indexes.sh

Then rerun verify.

Operating rules

• Treat raw history / transcripts as source of truth.
• Treat memory/LIVE_CONTEXT_PACKET.md as working memory, not durable storage.
• Do not treat retrieved-memory injection as new durable truth.
• Prefer repo wrappers (scripts/context-refresh*) over ad-hoc manual command chains.
• When status docs and runtime disagree, trust runtime checks after rebuild.

Read these references when needed

• references/commands.md — exact command map for refresh / rebuild / verify / inspect
• references/docs-map.md — which doc is design vs status vs restore vs checklist

Common files to inspect

• memory-system/MILESTONE_STATUS.md
• docs/designs/MEMORYLAB_MEMORY_SYSTEM_MILESTONE_RESTORE.md
• docs/designs/MEMORYLAB_MEMORY_SYSTEM_BLUEPRINT.md
• memory/ACTIVE_TASK_STATE.md
• memory/LIVE_CONTEXT_PACKET.md
• memory/RETRIEVAL_CONTEXT_BUNDLE.json
• history/transcripts/*.md

Default debug order

When output looks wrong, inspect in this order:

1. memory/ACTIVE_TASK_STATE.md
2. memory/LIVE_CONTEXT_PACKET.md
3. memory/RETRIEVAL_CONTEXT_BUNDLE.json
4. history/transcripts/*.md
5. memory-system/index/memory.db freshness / rebuild state

Compatibility rule

This skill operates the real sidecar already implemented in this repo. It should complement:

• context-manager
• live-context-management
• long-term-memory

Use this skill when the task is about running or auditing the built system, not just designing one.