hmem-mcp 5.0.0 → 5.1.21

package/skills/hmem-config/SKILL.md

@@ -1,191 +1,156 @@
 ---
 name: hmem-config
 description: >
-  View and change hmem settings, including sync configuration. Use when the user
-  types /hmem-config or asks to change memory settings, adjust parameters, configure
-  hmem, or set up / manage hmem-sync for cross-device synchronization.
+  View and change hmem memory settings, hooks, sync, and checkpoint configuration.
+  Use this skill whenever the user types /hmem-config, asks to change memory settings,
+  adjust parameters, tune bulk-read behavior, configure auto-checkpoints, manage
+  hmem-sync, or troubleshoot memory-related issues. Also trigger when the user asks
+  things like "how often does auto-save fire", "why is my context so large",
+  "change checkpoint to auto", "how many tokens does startup cost", or "set up sync".
 ---
 
 # hmem-config — View and Change Settings
 
-## Step 1 — Find the config file
+This skill guides you through reading, explaining, and updating hmem's configuration. The config controls how memory is stored, displayed, checkpointed, and synced across devices.
 
-The config file is `hmem.config.json` in the `HMEM_PROJECT_DIR` directory.
+## Locate and read the config
 
-Find it:
-```bash
-# Check the MCP environment variable first
-echo $HMEM_PROJECT_DIR
+The config lives at `hmem.config.json` inside the hmem project directory. With an agent ID, it's typically at `~/.hmem/Agents/<NAME>/hmem.config.json`. Without one, `~/.hmem/hmem.config.json`.
 
-# Common locations:
-# Global:  ~/.hmem/hmem.config.json
-# Project: ./hmem.config.json
-```
+Read the file directly — don't ask the user where it is. If it doesn't exist, offer to create one (only non-default values need to be specified).
+
+The config uses a unified format with a `"memory"` block and an optional `"sync"` block:
 
-If the file does not exist, offer to create it with defaults (see Step 3).
-
-## Step 2 — Read and display current settings
-
-Read the file and show the user a clear table of current values vs. defaults:
-
-| Parameter | Current value | Default | What it does |
-|-----------|--------------|---------|--------------|
-| `maxL1Chars` | … | 120 | Max characters for Level 1 summaries (the one-liner shown at session start). Keep short — this is what the agent always sees. |
-| `maxLnChars` | … | 50000 | Max characters for deeper levels (L2–L5). Controls how much detail you can store per node. |
-| `maxDepth` | … | 5 | How many nesting levels are available (1–5). 5 is the maximum. |
-| `defaultReadLimit` | … | 100 | Max entries returned by a single `read_memory()` call. |
-| `maxTitleChars` | … | 50 | Max characters for entry titles (auto-extracted from first line). Shown in `titles_only` mode and as navigation labels. |
-| `accessCountTopN` | … | 5 | Top-N most-accessed entries always get L2 inlined in bulk reads ("organic favorites"). These are shown with a [★] marker. Set to 0 to disable. |
-| `prefixes` | … | P,L,T,E,D,M,S,N,H,R | (P)roject, (L)esson, (T)ask, (E)rror, (D)ecision, (M)ilestone, (S)kill, (N)avigator, (H)uman. Custom prefixes merged with defaults. |
-| `prefixDescriptions` | … | (see below) | Human-readable descriptions for each prefix category, used as group headers in bulk reads. |
-| `bulkReadV2.topAccessCount` | … | 3 | Number of top-accessed entries to expand in V2 bulk reads. |
-| `bulkReadV2.topNewestCount` | … | 5 | Number of newest entries to expand in V2 bulk reads. |
-| `bulkReadV2.topObsoleteCount` | … | 3 | Number of obsolete entries to keep visible ("biggest mistakes"). |
-| `bulkReadV2.topSubnodeCount` | … | 3 | Number of entries with the most sub-nodes to always expand. Shown with `[≡]` marker. |
-
-### Bulk-Read Algorithm (V2.1)
-
-The bulk-read algorithm groups entries by prefix category and uses smart expansion:
-
-- **Expanded entries**: newest (top N), most-accessed (top N), and all favorites → show ALL L2 children + links
-- **[♥] Favorites**: always expanded, marked with [♥]
-- **[★] Top-accessed**: most-accessed entries per prefix, marked with [★]
-- **Obsolete entries**: top N by weighted score shown with `[!]`, rest hidden
-- **Per-prefix guarantee**: each category's youngest + most-accessed entry is always expanded
-- **Time-weighted scoring**: "most-accessed" uses `access_count / log2(age_in_days + 2)` — newer entries with fewer accesses can outrank older ones. This prevents old entries from dominating just because they had more time to accumulate accesses.
-
-**Compact title listing** — `read_memory(titles_only=true)`:
-- V2 selection still applies (only the important entries are shown)
-- But output is compact: one line per entry with `(N)` child count hints
-- Expanded entries (favorites, top-accessed) show their L2 children titles inline
-- Use for quick orientation or as a table of contents
-
-Tune via `bulkReadV2`:
 ```json
 {
-  "bulkReadV2": {
-    "topAccessCount": 3,
-    "topNewestCount": 5,
-    "topObsoleteCount": 3,
-    "topSubnodeCount": 3
-  }
+  "memory": { ... },
+  "sync": { ... }
 }
 ```
 
-### prefixDescriptions
+## Show current settings
+
+Present a table of current values vs. defaults. Only highlight values that differ from defaults — the user cares about what they've customized, not the full list.
+
+### Core parameters
+
+| Parameter | Default | Purpose |
+|-----------|---------|---------|
+| `maxCharsPerLevel` | [200, 2500, 10000, 25000, 50000] | Character limits per tree level [L1–L5]. L1 is always loaded at startup, so keeping it short saves tokens across every session. L5 is raw data, rarely accessed. |
+| `maxDepth` | 5 | Tree depth (1–5). Most users need 5. Lower values save storage but lose granularity. |
+| `defaultReadLimit` | 100 | Max entries per bulk read. Lower = faster startup, higher = more complete overview. |
+| `maxTitleChars` | 50 | Auto-extracted title length. Only applies to entries without explicit `>` body format — entries with `>` use the first non-body line as title verbatim. Titles are navigation labels — too short truncates meaning, too long wastes space. |
+| `accessCountTopN` | 5 | Entries with highest access count get [★] and auto-expand in bulk reads. These are "organic favorites" — the things the agent keeps coming back to. |
+
+### Checkpoint and session parameters (v5+)
 
-Default descriptions used as group headers in bulk reads:
+These control the automatic knowledge extraction pipeline:
 
+| Parameter | Default | Purpose |
+|-----------|---------|---------|
+| `checkpointMode` | `"remind"` | **`"auto"`** spawns a Haiku subagent in the background every N exchanges — it reads the conversation, extracts lessons/errors/decisions, and writes them via MCP tools. The main agent is never interrupted. **`"remind"`** injects a prompt asking the main agent to save manually — simpler but interrupts flow. |
+| `checkpointInterval` | 20 | Exchanges between checkpoints. Counted in the active O-entry, not per session — so 10 messages on your laptop + 10 on your server = checkpoint fires at 20. Set to 0 to disable. |
+| `recentOEntries` | 10 | How many recent session logs to show when loading a project. All entries include full user/agent exchanges (L4/L5), not just titles. Higher = more context but more tokens at project load. |
+| `contextTokenThreshold` | 100000 | When cumulative hmem output exceeds this, the agent is told to flush context and /clear. Prevents runaway token usage in long sessions. Set to 0 to disable. |
+
+### load_project display (v5.1.8+)
+
+Controls which P-entry sections are expanded when loading a project:
+
+| Parameter | Default | Purpose |
+|-----------|---------|---------|
+| `loadProjectExpand.withBody` | `[1]` | L2 section seq numbers where L3 children show title + body content. Default: `.1 Overview` — shows full architecture/state/goals detail. |
+| `loadProjectExpand.withChildren` | `[6, 8]` | L2 section seq numbers where all L3 children are listed as titles. Default: `.6 Bugs`, `.8 Open Tasks` — all items visible at a glance. |
+
+Sections not in either list show L3 titles only in compact mode. Example config:
 ```json
-{
-  "prefixDescriptions": {
-    "P": "(P)roject experiences and summaries",
-    "L": "(L)essons learned and best practices",
-    "T": "(T)asks and work items",
-    "E": "(E)rrors encountered and their fixes",
-    "D": "(D)ecisions and their rationale",
-    "M": "(M)ilestones and achievements",
-    "S": "(S)kills and technical knowledge",
-    "N": "(N)avigation and context notes",
-    "H": "(H)uman — knowledge about the user",
-    "R": "(R)ules — user-defined rules and constraints"
-  }
-}
+{ "memory": { "loadProjectExpand": { "withBody": [1, 4], "withChildren": [6, 8, 9] } } }
 ```
+This would expand Overview + Context with body, and list all Bugs + Tasks + Ideas as titles.
 
-Custom prefixes automatically get their name as the description. Override with explicit descriptions in config.
+### Bulk-read tuning
 
-## Step 3 — Ask the user what to change
+The bulk-read algorithm decides which entries get expanded (full L2 detail) vs. compressed (title only). Most users don't need to touch these — the defaults work well up to ~500 entries.
 
-Ask the user which parameter(s) they want to adjust. For each one:
+| Parameter | Default | Purpose |
+|-----------|---------|---------|
+| `bulkReadV2.topNewestCount` | 5 | Newest entries expanded. Increase if you want more recent context at startup. |
+| `bulkReadV2.topAccessCount` | 3 | Most-accessed entries expanded (time-weighted: `access_count / log2(age_days + 2)`). |
+| `bulkReadV2.topObsoleteCount` | 3 | Obsolete entries kept visible — "biggest mistakes" are still worth seeing. |
+| `bulkReadV2.topSubnodeCount` | 3 | Entries with most children expanded. These tend to be the most detailed/important. |
 
-1. Explain the tradeoff (e.g. higher `maxL1Chars` = more context at startup but wastes tokens)
-2. Show the current value and the recommended range
-3. Ask for the new value
-4. Validate the input (numbers must be positive integers, tiers must be valid JSON)
+### Prefixes
 
-**Recommended ranges:**
+Default: P, L, T, E, D, M, S, N, H, R, O, I. Custom prefixes are merged with defaults — they don't replace them. Each prefix can have a custom description used as group header in bulk reads.
 
-| Parameter | Min | Max | Notes |
-|-----------|-----|-----|-------|
-| `maxL1Chars` | 60 | 200 | Below 60: too terse. Above 200: wastes token budget at every spawn. |
-| `maxLnChars` | 1000 | 100000 | Higher = more detail possible, but rarely read. |
-| `maxDepth` | 2 | 5 | 3 is enough for most users. 5 for complex multi-agent setups. |
-| `defaultReadLimit` | 20 | 500 | Lower if startup feels slow. Higher if you have many entries. |
-| `maxTitleChars` | 20 | 100 | Below 30: titles truncated too aggressively. 50 is a good default. |
-| `accessCountTopN` | 0 | 20 | 0 = disabled. 5 is a good default. Raise if you have many frequently-accessed entries you want always visible. |
-| `bulkReadV2.topAccessCount` | 0 | 20 | How many most-accessed entries (by time-weighted score) get full expansion. |
-| `bulkReadV2.topNewestCount` | 0 | 20 | How many newest entries get full expansion. |
-| `bulkReadV2.topObsoleteCount` | 0 | 20 | How many obsolete entries stay visible in bulk reads. |
-| `bulkReadV2.topSubnodeCount` | 0 | 20 | How many entries with the most sub-nodes always get expanded. 0 = disabled. |
+## Help the user make changes
 
-**For custom prefixes:** Ask for a single letter + label (e.g. `R = Research`). Remind the user that custom prefixes are added on top of the defaults — they don't replace them.
+For each parameter the user wants to change:
 
-## Step 4 — Write the updated config
+1. **Explain the tradeoff** in plain language — what gets better, what gets worse
+2. **Show the recommended range** (see below)
+3. **Validate** before writing — numbers must be positive, arrays must be valid JSON
 
-Write the updated `hmem.config.json`. Only include keys that differ from defaults — keep the file clean.
+### Recommended ranges
 
-Then tell the user:
-- Which values were changed
-- That the change takes effect **immediately** — no restart needed
-- That `maxL1Chars` and `maxLnChars` only affect new entries written after the change (existing entries are not reformatted)
+| Parameter | Range | Guidance |
+|-----------|-------|----------|
+| `maxCharsPerLevel[0]` (L1) | 60–300 | Below 60 is too terse for useful summaries. Above 300 wastes tokens on every bulk read — L1 is loaded at every session start. |
+| `maxCharsPerLevel[4]` (L5) | 1000–100000 | Raw data storage. Higher allows more verbatim content but L5 is rarely loaded. |
+| `maxDepth` | 2–5 | 3 suffices for simple setups. 5 for multi-agent or complex projects. |
+| `checkpointMode` | `"auto"` or `"remind"` | Recommend `"auto"` — it's non-disruptive and produces better results because Haiku has MCP access to check for duplicates. Auto-checkpoints also write rolling summaries (`[CP]` nodes) and tag skill-dialog exchanges for filtering. |
+| `checkpointInterval` | 0–100 | 20 is a good balance. Lower = more frequent saves (more Haiku cost). 0 = disabled. |
+| `recentOEntries` | 0–20 | 10 is the sweet spot. With checkpoint summaries, `load_project` shows summary + recent exchanges only — much more compact than raw exchange dumps. |
+| `contextTokenThreshold` | 0–500000 | 100k is recommended for most models. Increase for 1M-context models. |
 
----
+### Common recipes
 
-## Step 5 — hmem-sync Status (check automatically)
+**"I want auto-checkpoints":**
+```json
+{ "memory": { "checkpointMode": "auto", "checkpointInterval": 20 } }
+```
 
-Check if hmem-sync is installed and configured. Run this check as part of every /hmem-config invocation.
+**"Startup is too slow / uses too many tokens":**
+Reduce `recentOEntries` (e.g., 5), `bulkReadV2.topNewestCount` (e.g., 3), or `maxCharsPerLevel[0]` (e.g., 150).
 
-```bash
-# Check if hmem-sync is installed
-which hmem-sync 2>/dev/null || npx hmem-sync --help 2>/dev/null
-```
+**"I have 500+ entries and bulk reads are noisy":**
+Increase `bulkReadV2.topAccessCount` and decrease `topNewestCount` — favor proven entries over new ones.
 
-### If hmem-sync is installed:
+## Write the updated config
 
-Check config and status:
-```bash
-npx hmem-sync status
+Write `hmem.config.json` with only non-default values. The config uses a `"memory"` wrapper:
+
+```json
+{
+  "memory": {
+    "checkpointMode": "auto"
+  },
+  "sync": { ... }
+}
 ```
 
-Show the user:
-| Setting | Value |
-|---------|-------|
-| Server URL | (from status output) |
-| User ID | (from status output) |
-| Last push | (timestamp or "never") |
-| Last pull | (timestamp or "never") |
-| Sync secrets | yes/no |
-
-Also check if `HMEM_SYNC_PASSPHRASE` is set in the MCP config (`.mcp.json` env block).
-If missing, warn: "Auto-sync is disabled. Add `HMEM_SYNC_PASSPHRASE` to your .mcp.json env to enable automatic push/pull on every read/write."
-
-### If hmem-sync is NOT installed:
-
-Tell the user:
-
-> **hmem-sync** enables zero-knowledge encrypted sync between devices. Your memories are encrypted client-side with AES-256-GCM before leaving your machine — the server only sees opaque blobs.
->
-> This lets you:
-> - Work on your PC, then continue on your laptop with full memory
-> - Back up your memories to a server you control
-> - Share memories between Claude Code, Gemini CLI, and OpenCode
->
-> Install: `npm install -g hmem-sync`
-> Setup: `npx hmem-sync setup` (first device) or `npx hmem-sync restore` (additional devices)
->
-> Want me to install it now?
-
-If the user says yes:
+After writing, tell the user:
+- Which values changed
+- Changes take effect **immediately** — no restart needed
+- `maxCharsPerLevel` only affects new entries (existing entries are not reformatted)
+
+## Check hmem-sync status
+
+Run this check as part of every /hmem-config invocation.
+
+**If installed** (`which hmem-sync`): run `npx hmem-sync status` and show server URL, user ID, last push/pull timestamps, and whether `HMEM_SYNC_PASSPHRASE` is set in `.mcp.json` (needed for auto-sync).
+
+**If not installed**: explain that hmem-sync enables zero-knowledge encrypted cross-device sync (AES-256-GCM, server sees only opaque blobs), and offer to install it:
 ```bash
 npm install -g hmem-sync
-npx hmem-sync setup
+npx hmem-sync connect
 ```
 
 ### Sync troubleshooting
 
-Common issues:
-- **"Config not found"** → run `npx hmem-sync setup` or `npx hmem-sync restore`
-- **401 Token verification failed** → passphrase has special characters that need shell escaping. Use `--passphrase` flag or set `HMEM_SYNC_PASSPHRASE` in .mcp.json env.
-- **0 entries after pull** → check `HMEM_AGENT_ID` matches between devices. Different agent IDs = different .hmem files.
-- **Updates always global**: `npm update -g hmem-sync` (NOT inside a project directory)
+| Problem | Fix |
+|---------|-----|
+| "Config not found" | Run `npx hmem-sync connect` |
+| 401 Token verification failed | Passphrase has special chars — set `HMEM_SYNC_PASSPHRASE` in .mcp.json env |
+| 0 entries after pull | `HMEM_AGENT_ID` must match between devices |
+| Update | `npm update -g hmem-sync` (always global, never inside a project) |

package/skills/hmem-curate/SKILL.md

@@ -94,14 +94,64 @@ fix_agent_memory(agent_name, "E0009", links=["P0001"])
 
 Don't over-link: only add links where the connection adds real navigational value, not just topical similarity.
 
-### Missing or poor titles
-Entries should have a meaningful title (~50 chars, configurable via `maxTitleChars`) for navigation. If an entry has no explicit title (auto-extracted from first `maxTitleChars` chars), check whether the auto-extracted title is useful. If it's truncated mid-word or vague, write a proper title:
+### Title/Body Quality (v5.1+)
 
-```
-fix_agent_memory(agent_name, id, content="Better Title\nOriginal L1 summary text")
-```
+Since v5.1, entries support explicit title/body separation via the `>` format. During curation:
+
+**Root entries (L1):**
+- Check if the auto-extracted title is meaningful. If it's truncated or vague, rewrite with explicit title + body:
+  ```
+  fix_agent_memory(agent_name, id, content="Clear navigation title\n> Original detailed L1 text that was too long for a title")
+  ```
+- Old entries without `>` still work — the title is auto-extracted from `level_1`. Only rewrite if the auto-title is genuinely bad.
+
+**Child nodes (L2+):**
+- Same principle: if a node has dense content, split into title + body:
+  ```
+  fix_agent_memory(agent_name, "L0003.2", content="Short node title\n> Detailed explanation\n> spanning multiple lines")
+  ```
+- Nodes with short, clear content don't need body separation — leave them as-is.
+
+**When to rewrite old entries:**
+- Auto-title is truncated mid-word or meaningless
+- Node has >200 chars of content crammed into one line
+- Content is valuable but hard to scan in listings (title = full text)
+
+**When NOT to rewrite:**
+- Title is already clear and navigable
+- Entry has low access count and marginal value (not worth the effort)
+
+### P-Entry Standard-Schema (R0009)
+
+All P-entries must follow the standard L2 structure (see R0009):
+`.1 Overview`, `.2 Codebase`, `.3 Usage`, `.4 Context`, `.5 Deployment`, `.6 Bugs`, `.7 Protocol`, `.8 Open tasks`, `.9 Ideas`
+
+During curation, check P-entries against this schema:
+- **Missing sections:** Add them using `append_agent_memory(agent_name, "P00XX", content="\tOverview\n\t\tCurrent state: ...")`
+- **Wrong order:** Flag and restructure — order is fixed per R0009
+- **Empty sections:** OK to omit, but if content exists it must be in the right section
+- **L1 body:** Should be a one-line project summary in format `Name | Status | Stack | Description`
+
+### O-entry curation (v5.1.2+)
+
+O-entries may need curation for titles, tags, and summaries:
+
+**Titles:**
+- Old O-entries may have title "unassigned" or generic titles like "hmem-mcp". Fix with `fix_agent_memory(agent_name, id, content="Descriptive session title")`.
+- Good title: "Title/Body Separation design + v5.1.0 release". Bad: "hmem-mcp".
+
+**Tags:**
+- O-entries should have a `#session` tag and optionally topic tags (e.g. `#npm`, `#release`, `#refactor`).
+- Add missing tags: `fix_agent_memory(agent_name, id, tags=["#session", "#release"])`
+
+**Checkpoint summaries:**
+- O-entries with many exchanges (>10) should have a `[CP]` checkpoint summary. If missing, write one:
+  `append_agent_memory(agent_name, "O00XX", content="\t[CP] Factual 3-8 sentence summary of the session")`
+  Then tag it: the auto-tagger picks up `[CP]` prefixed nodes on the next checkpoint run.
 
-For child nodes, titles are always auto-extracted — no action needed.
+**Special tagged nodes — do not modify:**
+- **`#checkpoint-summary`** nodes: Auto-generated `[CP]` summaries. Leave as-is.
+- **`#skill-dialog`** exchange nodes: Skill activations filtered from `load_project`. Leave as-is.
 
 ### Stale entries — auto-mark obsolete
 

package/skills/hmem-new-project/SKILL.md

@@ -0,0 +1,164 @@
+---
+name: hmem-new-project
+description: >
+  Create a new P-entry following the R0009 standard schema. Asks key questions,
+  optionally scans the codebase, and writes a complete project entry with all
+  required sections. Use when the user says "neues Projekt", "new project",
+  "Projekt anlegen", or "/hmem-new-project".
+---
+
+# /hmem-new-project — New Project Entry
+
+Create a complete P-entry following the R0009 standard schema. This skill ensures every project starts with a proper structure.
+
+---
+
+## Step 1: Does a codebase exist?
+
+Ask the user first:
+
+> "Gibt es bereits eine Codebase für dieses Projekt? Wenn ja, in welchem Verzeichnis?"
+
+**If yes (path provided):**
+- Scan the directory: read README, CLAUDE.md, package.json/Cargo.toml/setup.py/etc.
+- Detect language, framework, dependencies, entry points
+- Use this to pre-fill Overview, Codebase, Usage, Deployment sections
+- Continue to Step 2 for context the code can't tell us
+
+**If no (new idea / planning phase):**
+- Skip codebase scan
+- All sections come from the user's answers
+- Focus on Overview (.1) and Context (.4) — Codebase (.2) stays minimal
+
+---
+
+## Step 2: Quick questions (one at a time)
+
+Ask these in order. Skip questions already answered by the codebase scan.
+
+1. **Name** — "Wie soll das Projekt heißen?" (short name for the L1 title)
+2. **Status** — "Status? Active / Paused / Planning / Mature / Archived"
+3. **Stack** — "Welche Technologien? (z.B. TS/React, AHK v2, Python/Flask)"
+4. **One-liner** — "Beschreib das Projekt in einem Satz"
+5. **Goal** — "Was ist das Hauptziel?"
+6. **Who/Why** — "Wer nutzt es und warum?" (target audience + motivation)
+7. **GitHub/Repo** — "Gibt es ein Repo? (URL oder 'nein')"
+8. **Deployment** — "Wie wird es deployed? (npm, exe, server, manual, noch nicht)"
+
+Stop asking if the user says "reicht" or "das war's" — fill remaining sections from context or leave them minimal.
+
+---
+
+## Step 3: Build the P-entry
+
+Construct the entry following R0009 schema strictly:
+
+```
+Name | Status | Stack | One-liner
+> Goal and context in 1-2 sentences
+\tOverview
+\t\tCurrent state: ...
+\t\tGoals: ...
+\t\tArchitecture: ... (from codebase scan or user description)
+\tCodebase
+\t\tEntry point: ... (from scan)
+\t\t... (key files/modules)
+\tUsage
+\t\tInstallation: ...
+\t\tCLI/API: ...
+\tContext
+\t\tInitiator: User, date
+\t\tTarget audience: ...
+\t\tBusiness context: ...
+\tDeployment
+\t\t... (from scan or user answer)
+\tBugs
+\tProtocol
+\tOpen tasks
+\tIdeas
+```
+
+**Rules:**
+- L1 format: `Name | Status | Stack | Description` (mandatory)
+- L1 body (>): 1-2 sentence project summary
+- All 9 sections must be present (.1 Overview through .9 Ideas)
+- Empty sections get a placeholder child: e.g. `\t\tNone yet`
+- If codebase was scanned: .2 Codebase lists key files with descriptions
+- .7 Protocol starts empty (O-entries will fill it automatically)
+- Tags: at least `#project` + language/framework tags
+
+---
+
+## Step 4: Write and activate
+
+```
+write_memory(prefix="P", content="...", tags=["#project", "#typescript", ...])
+```
+
+Then activate it:
+```
+update_memory(id="P00XX", active=true)
+```
+
+Show the user the created entry:
+```
+read_memory(id="P00XX", depth=2)
+```
+
+---
+
+## Step 5: Link related entries
+
+Check if there are existing L/D/E/T entries that should be linked:
+```
+read_memory(search="project name or keywords")
+```
+
+If found, add links:
+```
+update_memory(id="P00XX", links=["T0044", "L0095"])
+```
+
+---
+
+## Codebase scan details
+
+When scanning a codebase directory, read in this order:
+1. `CLAUDE.md` or `AGENTS.md` — richest project context
+2. `README.md` — overview, installation, usage
+3. `package.json` / `Cargo.toml` / `setup.py` / `go.mod` — name, version, deps, scripts
+4. `.github/workflows/` — CI/CD setup
+5. `src/` or main source directory — entry points, key modules
+6. `docs/` — any existing specs or designs
+
+Extract:
+- Project name and version
+- Language and framework
+- Entry point(s)
+- Key modules/files (max 10-15)
+- Build/run commands
+- Test commands
+- Dependencies (major ones only)
+
+Do NOT read every file — scan directory structure and read key files only.
+
+---
+
+## Example output
+
+```
+EasySAP | Active | AHK v2/SAP GUI Scripting | SAP Freigabeprozess Automatisierung
+> Automatisiert Status-Übergänge, PDF-Prüfungen, Spezifikations-Verknüpfung und FPR-Erstellung via SAP GUI COM Scripting.
+  .1 Overview
+    .1.1 Current state: Production, läuft auf Server-VM mit 3 SAP-Sessions
+    .1.2 Goals: Vollautomatischer Freigabeprozess ohne manuelle SAP-Interaktion
+    .1.3 Architecture: Client/Server via Shared Network Drive (U:\ESAP\)
+  .2 Codebase
+    .2.1 Easy-SAP_Server.ahk — Haupt-Automations-Engine (Polling-Loop, SAP-Sessions, Status-Pipeline)
+    .2.2 Easy-SAP_Client.ahk — Lightweight Client (Hotkeys, Task-Erstellung)
+    .2.3 EasySAP_Shared.ahk — Shared Functions (Logging, Session-Management, Email)
+  .3 Usage
+    .3.1 Server: AutoHotkey64.exe Easy-SAP_Server.ahk
+    .3.2 Client: Alt+F (neue Aufgabe), Alt+X (beenden)
+  ...
+```