Memory System Sidecar
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:
CODEBLOCK0
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:
CODEBLOCK1
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:
CODEBLOCK2
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 - INLINECODE5 — which doc is design vs status vs restore vs checklist
Common files to inspect
- - INLINECODE6
- INLINECODE7
- INLINECODE8
- INLINECODE9
- INLINECODE10
- INLINECODE11
- INLINECODE12
Default debug order
When output looks wrong, inspect in this order:
- 1. INLINECODE13
- INLINECODE14
- INLINECODE15
- INLINECODE16
- INLINECODE17 freshness / rebuild state
Compatibility rule
This skill operates the real sidecar already implemented in this repo. It should complement:
- - INLINECODE18
- INLINECODE19
- INLINECODE20
Use this skill when the task is about running or auditing the built system, not just designing one.
内存系统侧车
使用此技能处理已实现的MemoryLab内存系统，而非仅停留在抽象规划层面。
系统边界如下：
- - 上下文管理器 = 热路径压缩器
- 内存侧车 = 长期提取、索引、检索、整合
- 桥接器 = 将检索到的内存反馈至ACTIVETASKSTATE/LIVECONTEXTPACKET，但不将其视为事实来源
快速工作流程
选择与任务匹配的最小工作流程。
1. 从真实会话刷新实时上下文+侧车
当用户提出以下要求时使用：
- - 刷新内存
- 从笔记本电脑会话重建上下文
- 从当前会话更新实时数据包
运行：
bash
./skills/memory-system-sidecar/scripts/refreshmemorysystem.sh
此脚本封装了仓库标准的端到端刷新路径。
2. 验证内存系统仍能通过测试
当用户询问以下问题时使用：
- - 内存系统是否正常工作？
- 里程碑5是否仍然有效？
- 运行检查
运行：
bash
./skills/memory-system-sidecar/scripts/verifymemorysystem.sh
此脚本运行主要单元测试及评估框架。
3. 仅重建索引
当评估/检索出现偏差或文档提及索引过时行为时使用。
运行：
bash
./skills/memory-system-sidecar/scripts/rebuildmemoryindexes.sh
然后重新运行验证。
操作规则
- - 将原始历史记录/转录视为事实来源。
- 将memory/LIVECONTEXTPACKET.md视为工作内存，而非持久存储。
- 不要将检索到的内存注入视为新的持久事实。
- 优先使用仓库封装脚本（scripts/context-refresh*），而非临时手动命令链。
- 当状态文档与运行时不一致时，在重建后信任运行时检查结果。
需要时查阅以下参考资料
- - references/commands.md — 刷新/重建/验证/检查的精确命令映射
- references/docs-map.md — 设计文档、状态文档、恢复文档、检查清单的区分说明
常用检查文件
- - memory-system/MILESTONESTATUS.md
- docs/designs/MEMORYLABMEMORYSYSTEMMILESTONERESTORE.md
- docs/designs/MEMORYLABMEMORYSYSTEMBLUEPRINT.md
- memory/ACTIVETASKSTATE.md
- memory/LIVECONTEXTPACKET.md
- memory/RETRIEVALCONTEXTBUNDLE.json
- history/transcripts/*.md
默认调试顺序
当输出异常时，按以下顺序检查：
- 1. memory/ACTIVETASKSTATE.md
- memory/LIVECONTEXTPACKET.md
- memory/RETRIEVALCONTEXTBUNDLE.json
- history/transcripts/*.md
- memory-system/index/memory.db 的新鲜度/重建状态
兼容性规则
此技能操作本仓库中已实现的真实侧车。它应与以下技能互补：
- - context-manager
- live-context-management
- long-term-memory
当任务涉及运行或审计已构建的系统（而非仅设计系统）时，使用此技能。
