--- name: load-mem description: load all memory layers (injected memory, StrictDoc project_memory, claude-mem history) plus core files to understand the project --- Build an understanding of this project from all available memory layers, then verify against core files and directory structure. **Memory layers (in priority order):** 1. **Injected project memory** — the `<project-memory>` block in your system prompt is already loaded. Do NOT re-fetch it. It is the authoritative source for constraints, config values, and conventions. 2. **File memory (StrictDoc)** — `docs/` is one StrictDoc project with two trees: `project_memory/` (memory: `decisions.sdoc` for 口径+初衷, `journal.sdoc` for progress) and `handbook/` (durable documents: specs, research, evaluations). Read the `.sdoc` files directly: - Nodes carry `UID` (stable anchor), `STATUS`, `STATEMENT` (the decision itself), `RATIONALE` (why it was made). - **STATUS discipline: only `Active` nodes are current canon.** `Deprecated`/`Superseded`/`Proposed` nodes are history — never quote them as current practice. When a node is Superseded, follow the relation to its successor. - To query precisely instead of reading everything: `strictdoc export --formats=json .` in `docs/`, then e.g. `jq '.DOCUMENTS[].NODES[] | select(.STATUS=="Active")' output/json/index.json`. 3. **Action history (claude-mem)** — a passive log of past tool activity with semantic search. If the files look stale or you need "what was actually done recently", use the `claude_mem_search` tool (fallback: `curl http://127.0.0.1:37700/...` worker API). Treat results as leads, not gospel — verify against files/git before acting on them. **Then ground it in code:** - Glob the directory structure and read core files to confirm the memory matches reality. - In projects not yet migrated, legacy markdown may still exist in other subdirectories under `docs/` (e.g. old `superpowers/`, `research/`). Skim for context but treat as historical until migrated into `docs/handbook/`. You can use ripgrep and naive grep, and load relevant skills as needed.
--- name: save-mem description: save memory according to current state and progress — durable facts to ctx_memory, narrative to StrictDoc project_memory ---
Record the current state so the next session can resume quickly. Extract the most core and important content. Be concise and to the point.
**Route by content type — do not dump everything into files:**
1.**Durable operational facts** (constraints, config values, naming conventions, architecture facts, hard-won workarounds) → write to `ctx_memory`. These are auto-injected into every future session. 2.**Project narrative** (progress, decisions with rationale, next steps) → the `docs/project_memory/` tree (see below). 3.**Durable documents** (specs, research reports, evaluations, design docs) → the `docs/handbook/<topic>/` tree (see below). 4.**Follow-ups for later** → `ctx_note`. 5.**Action details** (which commands ran, which files were touched) → do NOT record. claude-mem captures tool activity automatically.
**Writing to `docs/project_memory/` (memory tree):** - **Decisions** go to `decisions.sdoc` as `[DECISION]` nodes: `UID` (DEC-XXX-NNN), `STATUS` (Proposed/Active/Deprecated/Superseded), `TITLE`, `STATEMENT` (the canon), `RATIONALE` (the original motivation — always fill this; losing it is a known pain point). - **Progress entries** go to `journal.sdoc` as `[TEXT]` nodes with a date UID (e.g. `JOURNAL-2026-08-26`), referencing decision UIDs where relevant. - **Never delete or rewrite a node.** To retire one: set `STATUS: Deprecated` or `Superseded` and add a `RELATIONS: - TYPE: Parent / VALUE: <successorUID> / ROLE: Supersedes` link from the successor node. - **Validate after every write**: run `strictdoc export .` in `docs/` (covers both trees). A parse error must be fixed immediately — never leave the tree broken. Environment: prefer plain `strictdoc` from the currently activated Python env (the agent shell usually inherits the user's conda/uv/venv env). If it's not on PATH, detect the project's env (e.g. `.venv/bin/strictdoc`, `uv run strictdoc`, or a named conda env) — do not assume `.venv`. - SDoc strict rules: one empty line between nodes, no content outside grammar elements, no empty optional fields (omit them). Sections use ONLY the double-bracket form `[[SECTION]]`/`[[/SECTION]]` — the single-bracket `[SECTION]` was removed in strictdoc 0.28.3 (processor error). If export fails with "[SECTION] elements are no longer supported", some file uses the single-bracket form — fix with: `find . -name '*.sdoc' -exec sed -i -e 's/^\[SECTION\]/[[SECTION]]/g' -e 's/^\[\/SECTION\]/[[\/SECTION]]/g' {} +` **Writing to `docs/handbook/` (document tree):** - One `.sdoc` per document under a topic subdir (e.g. `handbook/research/`, `handbook/specs/`). - `[DOCUMENT]` header has no UID field — use `TITLE:` + `DATE:`; add `OPTIONS:` with `MARKUP: Markdown` (the default RST chokes on ``` fences and `backticks`). - Map `##` headings to `[[SECTION]]` + `[TEXT]` nodes; **every section must be closed with `[[/SECTION]]`**. - Keep the content verbatim; structure is the only thing you add. Chinese is preferable for node content, but English is acceptable; you may mix. Clarity matters most.
--- name: migrate-mem description: migrate an existing project's scattered/flat legacy memory files and documents into the three-layer memory system (ctx_memory + StrictDoc project_memory/handbook). Use when adopting the memory stack in a project that already has accumulated messy memory notes or docs. ---
Migrate legacy memory files into the three-layer system WITHOUT losing information or misjudging what is still current. Work in phases; the classification plan must be reviewed by the human before any writing.
**Prerequisites (verify first, stop if missing):** strictdoc env installed (pin the version, e.g. `strictdoc==0.28.1`, and keep it identical across machines — GitHub releases run ahead of PyPI and 0.28.3 removes single-bracket `[SECTION]`), `docs/` StrictDoc skeleton exists in the v2 layout (config at `docs/strictdoc_config.py` + `project_memory/` + `handbook/` trees), project `AGENTS.md` trigger block in place. If the skeleton is absent or a different layout, stop and ask the human — do not improvise a restructure.
## Phase 0 — Safety
- Copy every legacy memory file to `docs/_memory_archive/` (OUTSIDE the two sdoc trees, preserving paths). Originals are only moved, never deleted, and only after the final report is accepted.
## Phase 1 — Inventory
- Find all memory-bearing files: old `docs/project_memory/*.md`, scattered NOTES/TODO files, spec/plan/research/evaluation docs under `docs/` subdirectories, root-level notes. - Read them fully (chunk large files; keep a ledger file so compaction loses nothing). Extract discrete items, each tagged: operational fact / decision / progress / durable document / action trivia / obsolete — with its source file path.
## Phase 2 — Classification plan (HUMAN CHECKPOINT)
- Route each item per the standard rules: durable operational fact → `ctx_memory`; decision → `[DECISION]` node; progress/status → `journal.sdoc`; durable document (spec/research/evaluation/design doc) → `docs/handbook/<topic>/` via md→sdoc wrapping (see Phase 3); pure action trivia → drop (claude-mem covers it). - Contradictions: pick the current canon, mark losers as `Superseded` with a relation to the winner. If you cannot tell which is current, mark the item `STATUS: Proposed` and flag it — do NOT guess. -**Never fabricate a RATIONALE.** Only write one when the original motivation is discernible from the source text; otherwise omit the field. An invented rationale is worse than a missing one. - Present the plan as a table (item → destination → STATUS → reason) and STOP for human approval. On first migration of a project, always stop; on later runs, stop only if conflicts or Proposed items exist.
## Phase 3 — Execute (after approval)
- UIDs: scan existing nodes, continue the sequence; topic prefixes (DEC-MEM-*, DEC-AUTH-*, ...). - Write `decisions.sdoc` / `journal.sdoc` nodes. STATEMENT keeps the original wording of the canon (light clarity edits only). -**Document wrapping (md → handbook sdoc)**: one md file → one `.sdoc` under `docs/handbook/<topic>/`. `[DOCUMENT]` header: `TITLE:` + `DATE:` (no UID field exists) + `OPTIONS:` with `MARKUP: Markdown`. Map `##` headings to `[[SECTION]]` + `[TEXT]` nodes (double brackets ONLY — single-bracket `[SECTION]` is removed in 0.28.3+); close every section with `[[/SECTION]]`. Content stays verbatim — you add structure, not prose. - Write `ctx_memory` entries for operational facts — list existing memories first to avoid duplicates. - Validate after EVERY file edit: `strictdoc export .` in `docs/`. Fix parse errors immediately. Prefer plain `strictdoc` from the activated Python env (conda/uv/venv — the agent shell usually inherits it); if not on PATH, detect the project's env instead of assuming `.venv`.
## Phase 4 — Report & archive
- Report: counts by destination, conflicts resolved (and which side won), `Proposed` items awaiting human confirmation, dropped trivia. - Move originals into `docs/_memory_archive/`. Confirm `strictdoc export .` still passes.
还有一个就是 AGENTS.md 的 tail 内容
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
<!-- memory-system:start --> ## Project Memory System
This project uses a three-layer memory system (Magic Context + StrictDoc + claude-mem).
-**At session start**: run the `load-mem` skill before doing substantial work. -**At milestones and before ending work**: run the `save-mem` skill.
### Rules that always apply (even if the skills are not loaded)
1.`docs/` is a single StrictDoc project with two trees: `project_memory/` (memory: decisions, journal) and `handbook/` (durable documents). Only nodes with `STATUS: Active` are current canon; `Deprecated`/`Superseded`/`Proposed` nodes are history — never quote them as current practice. 2. Never delete or rewrite memory nodes. Retire via `STATUS` change plus a `Supersedes` relation to the successor node. 3. After editing any `.sdoc` file, validate immediately: run `strictdoc export .` inside `docs/`. Prefer the `strictdoc` on PATH (the activated conda/uv/venv env is inherited by the agent shell); if absent, detect the project env (e.g. `.venv/bin/strictdoc`, `uv run strictdoc`) — do not assume a specific env manager. Never leave the tree broken. 4. On conflict between memory sources, `ctx_memory` (the injected `<project-memory>` block) wins.
(Procedures for reading/writing memory live in the `load-mem`/`save-mem` skills — keep this file short.) <!-- memory-system:end -->