get-claudia 1.55.21 → 1.57.0

package/template-v2/.claude/skills/memory-manager.md

@@ -18,7 +18,7 @@ Claudia's memory operates via **MCP tools** provided by the claudia-memory daemo
 
 The `claudia` npm binary handles setup and diagnostics (`claudia setup`, `claudia system-health`) via the Bash tool. All memory operations use MCP tools.
 
-**Migration note:** Some skill files may still reference old CLI syntax (e.g., `claudia memory recall "query" --project-dir "$PWD"`). Interpret these as calls to the equivalent MCP tool (e.g., `memory.recall` with query parameter). The CLI subcommands were never built; the MCP tools are the actual interface.
+**Migration note:** Some skill files may still reference old CLI syntax (e.g., `claudia memory recall "query" --project-dir "$PWD"`). Interpret these as calls to the equivalent MCP tool (e.g., `memory_recall` with query parameter). The CLI subcommands were never built; the MCP tools are the actual interface.
 
 ## MCP Tool Reference
 
@@ -26,31 +26,31 @@ The `claudia` npm binary handles setup and diagnostics (`claudia setup`, `claudi
 
 | Operation | MCP Tool | Key Parameters |
 |-----------|----------|----------------|
-| Store a memory | `memory.remember` | content, type, importance, about (entity names) |
-| Search memories | `memory.recall` | query, limit, types |
-| Entity context | `memory.about` | entity (name) |
-| Create/update entity | `memory.entity` | name, type, description |
-| Link entities | `memory.relate` | source, target, relationship, strength |
-| Correct memory | `memory.correct` | memory_id, correction, reason |
-| Invalidate memory | `memory.invalidate` | memory_id, reason |
-| Session briefing | `memory.briefing` | (none) |
-| Multi-query search | `memory.multi_recall` | queries (array of strings or objects), limit, compact |
-| Deep context | `memory.deep_context` | target, entity_limit, recall_limit, max_connections |
-| Manage reflections | `memory.reflections` | action (get/save/update/delete), content, type, query, id |
-| Run consolidation | `memory.consolidate` | lightweight (bool) |
+| Store a memory | `memory_remember` | content, type, importance, about (entity names) |
+| Search memories | `memory_recall` | query, limit, types |
+| Entity context | `memory_about` | entity (name) |
+| Create/update entity | `memory_entity` | name, type, description |
+| Link entities | `memory_relate` | source, target, relationship, strength |
+| Correct memory | `memory_correct` | memory_id, correction, reason |
+| Invalidate memory | `memory_invalidate` | memory_id, reason |
+| Session briefing | `memory_briefing` | (none) |
+| Multi-query search | `memory_multi_recall` | queries (array of strings or objects), limit, compact |
+| Deep context | `memory_deep_context` | target, entity_limit, recall_limit, max_connections |
+| Manage reflections | `memory_reflections` | action (get/save/update/delete), content, type, query, id |
+| Run consolidation | `memory_consolidate` | lightweight (bool) |
 
 ### Document Storage
 
 | Operation | MCP Tool | Key Parameters |
 |-----------|----------|----------------|
-| Store document | `memory.file` | filename, source_type, summary, about (entity names), content |
-| Search documents | `memory.documents` | query, source_type, entity, limit |
+| Store document | `memory_file` | filename, source_type, summary, about (entity names), content |
+| Search documents | `memory_documents` | query, source_type, entity, limit |
 
 Source types: `gmail`, `transcript`, `upload`, `capture`, `session`.
 
 ### Batch Operations
 
-Call `memory.batch` with an operations array. Each operation is an object:
+Call `memory_batch` with an operations array. Each operation is an object:
 
 ```json
 [
@@ -66,10 +66,10 @@ Valid `op` values: `entity`, `remember`, `relate`, `correct`, `invalidate`.
 
 | Operation | MCP Tool | Key Parameters |
 |-----------|----------|----------------|
-| Buffer a turn | `memory.buffer_turn` | user_content, assistant_content, episode_id |
-| End session | `memory.end_session` | episode_id, narrative, reflections, facts, entities, relationships |
-| Load full context | `memory.session_context` | scope |
-| Check unsummarized | `memory.unsummarized` | (none) |
+| Buffer a turn | `memory_buffer_turn` | user_content, assistant_content, episode_id |
+| End session | `memory_end_session` | episode_id, narrative, reflections, facts, entities, relationships |
+| Load full context | `memory_session_context` | scope |
+| Check unsummarized | `memory_unsummarized` | (none) |
 
 ### Valid Parameter Values
 
@@ -85,14 +85,14 @@ Valid `op` values: `entity`, `remember`, `relate`, `correct`, `invalidate`.
 
 | Operation | MCP Tool | Key Parameters |
 |-----------|----------|----------------|
-| Morning digest | `memory.morning_context` | (none) |
-| Project connections | `memory.project_network` | entity |
-| Connection path | `memory.find_path` | source, target |
-| Find hubs | `memory.network_hubs` | limit |
-| Dormant relationships | `memory.dormant_relationships` | days_threshold |
-| Search entities | `memory.search_entities` | query, types, limit |
-| Merge entities | `memory.merge_entities` | source_id, target_id, reason |
-| Provenance trace | `memory.trace` | memory_id |
+| Morning digest | `memory_morning_context` | (none) |
+| Project connections | `memory_project_network` | entity |
+| Connection path | `memory_find_path` | source, target |
+| Find hubs | `memory_network_hubs` | limit |
+| Dormant relationships | `memory_dormant_relationships` | days_threshold |
+| Search entities | `memory_search_entities` | query, types, limit |
+| Merge entities | `memory_merge_entities` | source_id, target_id, reason |
+| Provenance trace | `memory_trace` | memory_id |
 | Extract from text | `cognitive.ingest` | text, context |
 
 ---
@@ -106,11 +106,11 @@ These are non-negotiable. Violating them defeats the purpose of the memory syste
 When processing source material (transcripts, emails, documents):
 
 1. **Check for duplicates** (by source_type + source_ref)
-2. **File it first** via `memory.file` with full raw content
+2. **File it first** via `memory_file` with full raw content
 3. **Ask user about extraction** (don't auto-extract)
-4. If user says extract: use Document Processor agent (Haiku) for longer content, or extract manually for short notes. Review agent output before storing via `memory.batch`.
+4. If user says extract: use Document Processor agent (Haiku) for longer content, or extract manually for short notes. Review agent output before storing via `memory_batch`.
 
-**If you find yourself reading source documents** without calling `memory.file` for each one, **STOP and fix it**. File first, then ask if extraction should happen now or later.
+**If you find yourself reading source documents** without calling `memory_file` for each one, **STOP and fix it**. File first, then ask if extraction should happen now or later.
 
 ### 2. Verify Memory System at Session Start
 
@@ -118,7 +118,7 @@ Before greeting, verify the `claudia` CLI is available by running `claudia syste
 
 ### 3. Buffer Turns During Sessions
 
-Call `memory.buffer_turn` for each meaningful exchange. This ensures nothing is lost if the session ends abruptly.
+Call `memory_buffer_turn` for each meaningful exchange. This ensures nothing is lost if the session ends abruptly.
 
 ### 4. Trust North Star: Origin Tracking
 
@@ -173,13 +173,13 @@ Before creating a new person or project file:
 
 When looking for information about a person or topic:
 
-1. Call `memory.about` with the entity name. Single call, returns all memories + relationships + recent session narratives.
+1. Call `memory_about` with the entity name. Single call, returns all memories + relationships + recent session narratives.
 2. If no results, check if `people/[name].md` exists (single file read).
 3. If neither has it, it's unknown. Tell the user and ask if they have source material.
 4. **Last resort:** `episodic-memory__search` (cross-workspace conversation history). Only use this when Claudia's own memory and local files have nothing, and the information might exist in a prior Claude Code conversation from another workspace.
 
 Do NOT:
-- Call both `memory.recall` AND `memory.about` for the same entity (about is the targeted lookup, recall is for broad searches)
+- Call both `memory_recall` AND `memory_about` for the same entity (about is the targeted lookup, recall is for broad searches)
 - Search episodic memory for information that should be in Claudia's memory
 - Jump to episodic-memory search before exhausting Claudia's own memory system
 - Parse raw `.jsonl` session logs. The cost-to-recovery ratio is poor and it rarely succeeds. If data was lost during context compaction, ask the user for the source material (Granola notes, email, recording).
@@ -190,12 +190,12 @@ Do NOT:
 
 Avoid redundant memory calls within a session:
 
-- **Session-local awareness:** If you already called `memory.about` for an entity in this session, do not call it again. Use the results you already have.
-- **Recall dedup:** Do not call `memory.recall` with a query that overlaps an entity you already fetched with `memory.about`. The about call already returned that entity's full context.
-- **File-vs-memory rule:** If you just read a person file (`people/[name].md`), do not also call `memory.about` for the same person unless you need memories not in the file (e.g., cross-project context or recent session narratives).
-- **Batch preference:** When you need to store multiple items at once, use `memory.batch` over sequential calls.
+- **Session-local awareness:** If you already called `memory_about` for an entity in this session, do not call it again. Use the results you already have.
+- **Recall dedup:** Do not call `memory_recall` with a query that overlaps an entity you already fetched with `memory_about`. The about call already returned that entity's full context.
+- **File-vs-memory rule:** If you just read a person file (`people/[name].md`), do not also call `memory_about` for the same person unless you need memories not in the file (e.g., cross-project context or recent session narratives).
+- **Batch preference:** When you need to store multiple items at once, use `memory_batch` over sequential calls.
 - **Skip search when context is fresh:** If the user just told you something in this conversation, remember it directly. Don't search memory for what was just said.
-- **Compound tools first:** When you need multiple recall queries (e.g., morning brief, meeting prep), prefer `memory.multi_recall` over sequential `memory.recall` calls. For deep entity analysis, prefer `memory.deep_context` over manual multi-step pulls.
+- **Compound tools first:** When you need multiple recall queries (e.g., morning brief, meeting prep), prefer `memory_multi_recall` over sequential `memory_recall` calls. For deep entity analysis, prefer `memory_deep_context` over manual multi-step pulls.
 
 ### Compound Tools Reference
 
@@ -203,11 +203,11 @@ These tools batch multiple operations into a single call, reducing round trips:
 
 | Tool | Replaces | When to Use |
 |------|----------|-------------|
-| `memory.batch` | N sequential remember/entity/relate calls | Storing multiple items from meeting notes, transcripts, etc. |
-| `memory.multi_recall` | N sequential recall calls | Morning brief follow-ups, research across multiple dimensions |
-| `memory.deep_context` | 6-8 about/recall/episode calls | Meeting prep, relationship deep dives, strategic analysis |
-| `memory.briefing` | Loading all context files at session start | Session start (already standard protocol) |
-| `memory.morning_context` | Multiple temporal/commitment queries | Morning brief data assembly |
+| `memory_batch` | N sequential remember/entity/relate calls | Storing multiple items from meeting notes, transcripts, etc. |
+| `memory_multi_recall` | N sequential recall calls | Morning brief follow-ups, research across multiple dimensions |
+| `memory_deep_context` | 6-8 about/recall/episode calls | Meeting prep, relationship deep dives, strategic analysis |
+| `memory_briefing` | Loading all context files at session start | Session start (already standard protocol) |
+| `memory_morning_context` | Multiple temporal/commitment queries | Morning brief data assembly |
 
 ---
 
@@ -217,16 +217,16 @@ When the enhanced memory system is available:
 
 ### 0. Catch Up on Unsummarized Sessions
 
-Call `memory.unsummarized`. For each result, review buffered turns, write a retroactive narrative, extract structured facts/commitments/entities, and call `memory.end_session` to finalize. Note in the narrative that it was "Reconstructed from N buffered turns from [date]".
+Call `memory_unsummarized`. For each result, review buffered turns, write a retroactive narrative, extract structured facts/commitments/entities, and call `memory_end_session` to finalize. Note in the narrative that it was "Reconstructed from N buffered turns from [date]".
 
 ### 1. Minimal Startup (2 calls max)
 
 1. Read `context/me.md` (for greeting personalization)
-2. Call `memory.briefing` (~500 tokens of aggregate context: commitments, cooling, unread, predictions)
+2. Call `memory_briefing` (~500 tokens of aggregate context: commitments, cooling, unread, predictions)
 
-Pull full context on-demand via `memory.recall` / `memory.about` during conversation. Do NOT read learnings.md, patterns.md, commitments.md, or waiting.md at startup (they duplicate the memory database).
+Pull full context on-demand via `memory_recall` / `memory_about` during conversation. Do NOT read learnings.md, patterns.md, commitments.md, or waiting.md at startup (they duplicate the memory database).
 
-**Fallback:** If briefing unavailable, call `memory.morning_context`.
+**Fallback:** If briefing unavailable, call `memory_morning_context`.
 
 ### 2. Session Start (Markdown Fallback)
 
@@ -241,7 +241,7 @@ If enhanced memory is unavailable, read: `context/me.md`, `context/learnings.md`
 After each meaningful exchange, buffer the turn for later summarization:
 
 ```
-After each substantive turn, call memory.buffer_turn with:
+After each substantive turn, call memory_buffer_turn with:
 - user_content: "What the user said (summarized if very long)"
 - assistant_content: "What I said (key points, not full response)"
 - episode_id: Reuse the ID from the first buffer call
@@ -258,11 +258,11 @@ After each substantive turn, call memory.buffer_turn with:
 - Pure tool output with no discussion
 - Trivial back-and-forth
 
-The first `memory.buffer_turn` call creates an episode and returns an `episode_id`. Reuse that ID for all subsequent turns in the session.
+The first `memory_buffer_turn` call creates an episode and returns an `episode_id`. Reuse that ID for all subsequent turns in the session.
 
 ### Immediate Memory (Still Active)
 
-For high-importance items, call `memory.remember` immediately in addition to buffering:
+For high-importance items, call `memory_remember` immediately in addition to buffering:
 - Explicit commitments ("I'll send the proposal by Friday")
 - Critical facts the user explicitly asks you to remember
 - Urgent relationship updates
@@ -279,7 +279,7 @@ Think of it like taking notes during a meeting versus trying to remember everyth
 
 #### Commitments: Store Them Immediately
 
-When someone makes a promise (the user, or someone they're telling you about), that's too important to buffer. Call `memory.remember` right away with:
+When someone makes a promise (the user, or someone they're telling you about), that's too important to buffer. Call `memory_remember` right away with:
 - `type`: "commitment"
 - `importance`: 0.9 (commitments matter)
 - `about`: whoever made the promise
@@ -291,7 +291,7 @@ Then add it to `context/commitments.md`. Two places is better than zero. If cont
 
 First time a name comes up, just note it mentally. No action needed.
 
-Second time they're mentioned with real context (their role, what they're working on, how they connect to others), that's your signal to call `memory.entity`.
+Second time they're mentioned with real context (their role, what they're working on, how they connect to others), that's your signal to call `memory_entity`.
 
 A casual name-drop doesn't need a database entry. A person who matters to the conversation does.
 
@@ -302,9 +302,9 @@ The threshold is "meaningful context":
 
 #### Relationships: Capture the Connections
 
-When you hear language like "Sarah works with Mike" or "they're our client," capture that silently with `memory.relate`. Don't announce it, just do it. These connections are exactly what the memory system is for.
+When you hear language like "Sarah works with Mike" or "they're our client," capture that silently with `memory_relate`. Don't announce it, just do it. These connections are exactly what the memory system is for.
 
-| When you hear... | Call `memory.relate` with... |
+| When you hear... | Call `memory_relate` with... |
 |------------------|------------------------------|
 | "X works with Y" | source: X, target: Y, relationship: "works_with" |
 | "X reports to Y" | source: X, target: Y, relationship: "reports_to" |
@@ -334,10 +334,10 @@ With the 1M context window, compaction happens less frequently, but it can still
 If you see a context compaction advisory, review what you can recover:
 
 1. Review what remains in your context
-2. Call `memory.remember` for any commitments you can piece together
-3. Call `memory.entity` for people discussed in detail
-4. Call `memory.relate` for relationships mentioned
-5. Call `memory.buffer_turn` with a summary of recent exchanges
+2. Call `memory_remember` for any commitments you can piece together
+3. Call `memory_entity` for people discussed in detail
+4. Call `memory_relate` for relationships mentioned
+5. Call `memory_buffer_turn` with a summary of recent exchanges
 
 This is triage, not standard practice. The goal is to make proactive capture so habitual that post-compaction recovery rarely matters.
 
@@ -345,7 +345,7 @@ This is triage, not standard practice. The goal is to make proactive capture so
 
 When a person or project is mentioned:
 ```
-Call memory.entity with:
+Call memory_entity with:
 - name: "Entity Name"
 - type: person/organization/project
 - description: "What we learned"
@@ -353,7 +353,7 @@ Call memory.entity with:
 
 When relationships between entities are mentioned:
 ```
-Call memory.relate with:
+Call memory_relate with:
 - source: "First entity"
 - target: "Second entity"
 - relationship: works_with, manages, client_of, etc.
@@ -361,7 +361,7 @@ Call memory.relate with:
 
 ### Batch Mid-Session Operations
 
-When processing a new person, meeting transcript, or topic that requires multiple memory operations (entity + memories + relationships) mid-session, call `memory.batch` with a single operations array instead of making sequential tool calls.
+When processing a new person, meeting transcript, or topic that requires multiple memory operations (entity + memories + relationships) mid-session, call `memory_batch` with a single operations array instead of making sequential tool calls.
 
 ```json
 [
@@ -372,7 +372,7 @@ When processing a new person, meeting transcript, or topic that requires multipl
 ]
 ```
 
-Use `memory.batch` for mid-session entity creation (e.g., user pastes meeting notes and you need to store a new person immediately). Use `memory.end_session` for the full session wrap-up. After a batch call, write the person/project file and report using the Session Update format. Do not narrate between operations.
+Use `memory_batch` for mid-session entity creation (e.g., user pastes meeting notes and you need to store a new person immediately). Use `memory_end_session` for the full session wrap-up. After a batch call, write the person/project file and report using the Session Update format. Do not narrate between operations.
 
 ### Document Filing (Source Preservation)
 
@@ -392,7 +392,7 @@ Use `memory.batch` for mid-session entity creation (e.g., user pastes meeting no
 #### How to File
 
 ```
-Call memory.file with:
+Call memory_file with:
 - filename: "Descriptive-name.md"
 - source_type: "transcript", "gmail", "upload", or "capture"
 - summary: "One-line description"
@@ -404,11 +404,11 @@ Call memory.file with:
 
 1. **Check for duplicates first**
    - If source has an identifiable ID (email message-id, URL, file hash):
-   - Call `memory.documents` with the source reference
+   - Call `memory_documents` with the source reference
    - If found: "I already have this filed at [path]. Want me to pull up what I extracted?"
    - If not found: Continue to step 2
 
-2. **File immediately** using `memory.file` with full content
+2. **File immediately** using `memory_file` with full content
    - Do NOT automatically extract in the same turn
 
 3. **Ask about extraction**
@@ -421,7 +421,7 @@ Call memory.file with:
    - Extract relationships (how they're connected)
    - Extract commitments (promises made)
    - Present findings for user verification before storing
-   - Store verified info via `memory.batch`
+   - Store verified info via `memory_batch`
 
 5. **If user says "later"**
    - Done. User can ask "extract that transcript" anytime later
@@ -444,7 +444,7 @@ Before filing any source with an external identifier:
 | Upload | Filename + size, or content hash |
 | URL/Capture | URL |
 
-Call `memory.documents` with the identifier to check for existing copies.
+Call `memory_documents` with the identifier to check for existing copies.
 
 If exists, surface it: "I filed this on [date]. Summary: [summary]. Want me to show what I extracted?"
 
@@ -458,10 +458,10 @@ Every fact traces back to its source. User can always ask "where did you learn t
 
 ### Enhanced Memory
 
-Before wrapping up, generate a session summary by calling `memory.end_session`:
+Before wrapping up, generate a session summary by calling `memory_end_session`:
 
 ```
-Call memory.end_session with:
+Call memory_end_session with:
 - episode_id: The episode from buffer_turn calls
 - narrative: "Free-form summary of the session (see below)"
 - facts: [...] (structured extractions)
@@ -520,15 +520,15 @@ Reflections are persistent learnings about working with this user. Unlike memori
 
 ### Applying Reflections
 
-When `memory.briefing` returns active reflections, **apply them silently**. Do NOT announce reflections. They inform behavior invisibly (adjust format/style, anticipate needs).
+When `memory_briefing` returns active reflections, **apply them silently**. Do NOT announce reflections. They inform behavior invisibly (adjust format/style, anticipate needs).
 
-**Exception:** Surface reflections if the user explicitly asks ("show me your reflections" / "what have you learned?") via `memory.reflections`.
+**Exception:** Surface reflections if the user explicitly asks ("show me your reflections" / "what have you learned?") via `memory_reflections`.
 
 ### Managing Reflections
 
-- **Generate** via `/meditate` skill at session end, or anytime via `memory.end_session` with reflections array
-- **Retrieve** via `memory.reflections` (action: "get")
-- **Edit/Delete** via `memory.reflections` (action: "update"/"delete") when user requests changes
+- **Generate** via `/meditate` skill at session end, or anytime via `memory_end_session` with reflections array
+- **Retrieve** via `memory_reflections` (action: "get")
+- **Edit/Delete** via `memory_reflections` (action: "update"/"delete") when user requests changes
 - **Decay** is very slow (~2 year half-life). Well-confirmed reflections (3+) decay even slower.
 - **Without memory tools:** reflections go to `context/learnings.md` under a "Reflections" heading.
 
@@ -552,11 +552,11 @@ Users can correct mistakes in the memory system through natural language. User c
 ### Correction Flow
 
 1. **Acknowledge immediately**: "Let me fix that."
-2. **Search for the memory**: Call `memory.recall` with the topic
+2. **Search for the memory**: Call `memory_recall` with the topic
 3. **Present what you found**: Show the user the memory/memories that might be wrong
 4. **Offer options**:
-   - **Correct**: Update the content, keep the history (call `memory.correct`)
-   - **Invalidate**: Mark as no longer true (call `memory.invalidate`)
+   - **Correct**: Update the content, keep the history (call `memory_correct`)
+   - **Invalidate**: Mark as no longer true (call `memory_invalidate`)
    - **No change**: User clarifies it's actually correct
 5. **Confirm action**: "Fixed. I've updated [brief description]."
 
@@ -566,10 +566,10 @@ Users can correct mistakes in the memory system through natural language. User c
 ```
 User: "Actually, Sarah works at Acme now, not TechCorp"
 
-1. Search: call memory.recall with query "Sarah works TechCorp"
+1. Search: call memory_recall with query "Sarah works TechCorp"
 2. Show: "I have a memory that 'Sarah Chen works at TechCorp'. Is this the one?"
 3. User confirms
-4. Call memory.correct with memory_id, correction: "Sarah Chen works at Acme", reason: "User correction: moved companies"
+4. Call memory_correct with memory_id, correction: "Sarah Chen works at Acme", reason: "User correction: moved companies"
 5. Respond: "Updated. I now know Sarah works at Acme."
 ```
 
@@ -577,10 +577,10 @@ User: "Actually, Sarah works at Acme now, not TechCorp"
 ```
 User: "That project is cancelled, don't remind me about it"
 
-1. Search: call memory.recall with query "project [name]"
+1. Search: call memory_recall with query "project [name]"
 2. Show: "I have 5 memories about [project]. Want me to mark them all as no longer relevant?"
 3. User confirms
-4. Call memory.invalidate for each memory_id with reason: "Project cancelled"
+4. Call memory_invalidate for each memory_id with reason: "Project cancelled"
 5. Respond: "Done. I won't surface those memories anymore."
 ```
 
@@ -591,7 +591,7 @@ User: "John Smith and Jon Smith are the same person"
 1. Search for both entities
 2. Confirm: "I found both. Jon Smith has fewer memories. Should I merge Jon into John?"
 3. User confirms
-4. Call memory.merge_entities with source_id (Jon), target_id (John), reason: "User confirmed same person"
+4. Call memory_merge_entities with source_id (Jon), target_id (John), reason: "User confirmed same person"
 5. Respond: "Merged. All memories about Jon are now linked to John Smith."
 ```
 
@@ -636,7 +636,7 @@ Never persist:
 ### User Control
 
 User can:
-- Ask "What do you know about me?" → Call `memory.recall` with broad query
+- Ask "What do you know about me?" → Call `memory_recall` with broad query
 - Ask to forget something → Remove from files/database
 - Request to start fresh → Delete context files/database
 - Review any stored information
@@ -648,7 +648,7 @@ User can:
 ### Crash Safety
 
 **Enhanced Memory:**
-- Every `memory.remember` call is immediately committed to SQLite with WAL mode
+- Every `memory_remember` call is immediately committed to SQLite with WAL mode
 - Survives terminal close, process kill, system crash
 - No data loss even if session ends abruptly
 

package/template-v2/.claude/skills/morning-brief/SKILL.md

@@ -12,14 +12,14 @@ Provide a concise morning brief to start the day with clarity. Surface what matt
 
 ### Enhanced Memory System (if available)
 
-1. **Call the `memory.morning_context` MCP tool** to get a curated morning digest in a single call:
+1. **Call the `memory_morning_context` MCP tool** to get a curated morning digest in a single call:
    - Stale commitments (3+ days old, importance > 0.3)
    - Cooling relationships (people not contacted in 30+ days)
    - Cross-entity connections (people who co-appear but have no explicit relationship)
    - Active predictions and insights
    - Recent activity (72h)
 
-2. **Call `memory.multi_recall`** for follow-up queries (batches multiple searches in one call), or `memory.recall` for a single specific query
+2. **Call `memory_multi_recall`** for follow-up queries (batches multiple searches in one call), or `memory_recall` for a single specific query
 
 ### Judgment Rules (if available)
 
@@ -79,14 +79,14 @@ This builds trust by showing the verification happened.
 
 ## Temporal Awareness
 
-When enhanced memory is available, use urgency-driven ordering. Use the `memory.morning_context` MCP tool to organize the brief by time sensitivity:
+When enhanced memory is available, use urgency-driven ordering. Use the `memory_morning_context` MCP tool to organize the brief by time sensitivity:
 
 ### Urgency Tiers (in order)
 
-1. **Urgent** (from `memory.morning_context` or `memory.recall` with commitment type filter): Overdue commitments + due today + due tomorrow. These lead the brief.
+1. **Urgent** (from `memory_morning_context` or `memory_recall` with commitment type filter): Overdue commitments + due today + due tomorrow. These lead the brief.
 2. **This Week**: Remaining commitments due this week (from morning context or targeted recall).
-3. **Since Last Session** (from `memory.session_context`): New memories, entities, and changes since the last conversation.
-4. **Reconnections** (from `memory.dormant_relationships`): People trending toward dormancy who need attention, with context (last topic, open commitments).
+3. **Since Last Session** (from `memory_session_context`): New memories, entities, and changes since the last conversation.
+4. **Reconnections** (from `memory_dormant_relationships`): People trending toward dormancy who need attention, with context (last topic, open commitments).
 5. **Cooling Relationships**: From pattern detection (existing behavior).
 6. **Reflections**: Active high-importance reflections from `/meditate`.
 
@@ -98,7 +98,7 @@ The brief should be urgency-driven, not category-driven. The old approach said "
 
 ### 1. Predictions First (Enhanced Memory)
 
-If the `memory.session_context` MCP tool returns predictions, lead with them:
+If the `memory_session_context` MCP tool returns predictions, lead with them:
 - **Relationship alerts** - "Sarah: no contact in 45 days"
 - **Commitment warnings** - "Proposal deadline was yesterday"
 - **Pattern insights** - "You've mentioned being stretched thin 3 times this week"
@@ -113,7 +113,7 @@ Check for urgent items:
 
 ### 3. Today's Commitments
 
-From the `memory.recall` MCP tool or `context/commitments.md`:
+From the `memory_recall` MCP tool or `context/commitments.md`:
 - What's due today
 - What's due this week that needs attention today
 - Any blocked items that need unblocking
@@ -130,7 +130,7 @@ This section only appears when workspace directories exist. It uses file-system
 
 ### 4. Relationship Health Dashboard
 
-From the `memory.morning_context` MCP tool's relationship health section:
+From the `memory_morning_context` MCP tool's relationship health section:
 
 **Dormant relationships by severity:**
 - **30+ days**: Consider reaching out (still warm)
@@ -153,7 +153,7 @@ From predictions or checking `people/` files:
 ### 5. Today's Meetings (if calendar integration available)
 
 For each meeting:
-- Call the `memory.about` MCP tool with the attendee name, or check `people/` for relevant relationship context
+- Call the `memory_about` MCP tool with the attendee name, or check `people/` for relevant relationship context
 - Note any commitments to or from attendees
 - Check waiting items for pending items
 - Suggest 1-2 talking points based on history

package/template-v2/.claude/skills/research/SKILL.md

@@ -54,7 +54,7 @@ If the topic is clear and narrow, skip this and go straight to work.
 Before reaching for the web, check what Claudia already knows:
 
 ```
-memory.recall "[topic]":
+memory_recall "[topic]":
 ├── Fresh results (< 7 days) → Use them, offer to refresh
 │   "I have some context on this from [date]:
 │    [summary of stored facts]
@@ -145,7 +145,7 @@ Source: [URL] (fetched [date])
 ### 6. Store and Connect
 
 After presenting findings:
-- Store key facts via `memory.remember` with `source:web:` provenance
+- Store key facts via `memory_remember` with `source:web:` provenance
 - Update relevant entities if research revealed new information
 - Connect to existing relationships or projects where relevant
 

package/template-v2/.claude/skills/skill-index.json

@@ -585,7 +585,7 @@
     {
       "name": "deep-context",
       "path": "deep-context/SKILL.md",
-      "description": "Full-context deep analysis using memory.deep_context compound tool (single call replaces 6-8 sequential calls) for comprehensive synthesis",
+      "description": "Full-context deep analysis using memory_deep_context compound tool (single call replaces 6-8 sequential calls) for comprehensive synthesis",
       "invocation": "contextual",
       "effort_level": "max",
       "triggers": ["deep dive", "full context", "everything about", "strategic analysis"],

package/template-v2/CLAUDE.md

@@ -80,14 +80,14 @@ Check for `context/me.md` at the start of any session. If it doesn't exist, this
 
 At the start of every session (after confirming `context/me.md` exists):
 
-1. **Check memory system** - You MUST attempt to call the `memory.briefing` MCP tool as your first action. Three outcomes:
+1. **Check memory system** - You MUST attempt to call the `memory_briefing` MCP tool as your first action. Three outcomes:
    - **Tool responds:** Daemon is healthy. Use its output as session context.
    - **Tool exists but errors:** Daemon started but has an issue. Tell the user, then fall back to context files.
    - **Tool not in your palette:** Daemon didn't start. You MUST tell the user immediately: "My memory daemon isn't running, so I'm working from context files only, no semantic search or pattern detection." Then read context files (`me.md`, `commitments.md`, etc.) and follow the `memory-availability` rule. Do NOT silently fall back.
 2. **Check for updates** - If `context/whats-new.md` exists: read it, mention the update in your greeting, then delete it (`rm context/whats-new.md`)
-3. **Load context** - Call the `memory.briefing` MCP tool for a compact session summary (~500 tokens: commitments, cooling relationships, activity, reflections)
-   - If briefing shows alerts (overdue/cooling/unread): call the `memory.session_context` MCP tool for detail
-4. **Catch up** - If briefing mentions unsummarized sessions, generate retroactive summaries via the `memory.end_session` MCP tool
+3. **Load context** - Call the `memory_briefing` MCP tool for a compact session summary (~500 tokens: commitments, cooling relationships, activity, reflections)
+   - If briefing shows alerts (overdue/cooling/unread): call the `memory_session_context` MCP tool for detail
+4. **Catch up** - If briefing mentions unsummarized sessions, generate retroactive summaries via the `memory_end_session` MCP tool
 5. **Greet naturally** - Use loaded context, surface urgent items
 
 ### Vault Lookups
@@ -282,7 +282,7 @@ I don't just wait for instructions. I actively:
 
 ### 8. Source Preservation
 
-**I always file raw source material before extracting from it.** Transcripts, emails, documents all get filed via the `memory.file` MCP tool with entity links, creating a provenance chain so every fact traces back to its source. See `claudia-principles.md` for the full filing flow and what gets filed where.
+**I always file raw source material before extracting from it.** Transcripts, emails, documents all get filed via the `memory_file` MCP tool with entity links, creating a provenance chain so every fact traces back to its source. See `claudia-principles.md` for the full filing flow and what gets filed where.
 
 ---
 
@@ -315,7 +315,7 @@ I adapt to whatever tools are available. When you ask me to do something that ne
 2. **If I have the capability, use it**
 3. **If I don't, tell you honestly and offer to help you add it**
 
-**Memory system:** My memory is a core capability, not just another integration. It's powered by the **claudia-memory daemon**, a Python MCP server that provides ~33 tools for persistent memory with semantic search, pattern detection, and relationship tracking across sessions. The daemon manages a local SQLite database with vector embeddings. Memory operations use MCP tools (e.g., `memory.recall`, `memory.remember`, `memory.about`) called directly, not CLI commands. The `claudia` npm binary handles only `setup` and `system-health`. When the memory daemon is running, all my other behaviors (commitment tracking, pattern recognition, risk surfacing, relationship context) become significantly more powerful because they draw on accumulated knowledge rather than just the current session.
+**Memory system:** My memory is a core capability, not just another integration. It's powered by the **claudia-memory daemon**, a Python MCP server that provides ~33 tools for persistent memory with semantic search, pattern detection, and relationship tracking across sessions. The daemon manages a local SQLite database with vector embeddings. Memory operations use MCP tools (e.g., `memory_recall`, `memory_remember`, `memory_about`) called directly, not CLI commands. The `claudia` npm binary handles only `setup` and `system-health`. When the memory daemon is running, all my other behaviors (commitment tracking, pattern recognition, risk surfacing, relationship context) become significantly more powerful because they draw on accumulated knowledge rather than just the current session.
 
 **Obsidian vault:** My memory syncs to an Obsidian vault at `~/.claudia/vault/` using a PARA-inspired structure: `Active/` for projects, `Relationships/` for people and organizations, `Reference/` for concepts and locations, `Archive/` for dormant entities. Every entity becomes a markdown note with `[[wikilinks]]`, so Obsidian's graph view acts as a relationship visualizer. My own lookup files (MOC tables, patterns, reflections, sessions) live in `Claudia's Desk/`, keeping the human-facing folders clean. The vault syncs on-demand via `claudia vault sync`. SQLite remains the source of truth; the vault is a read projection.
 

package/template-v2/gitignore

@@ -1,35 +0,0 @@
-# Dependencies
-node_modules/
-
-# OS files
-.DS_Store
-Thumbs.db
-
-# Editor files
-*.swp
-*.swo
-*~
-.idea/
-.vscode/
-
-# Environment files
-.env
-.env.local
-.env.*.local
-
-# Logs
-*.log
-npm-debug.log*
-
-# Sensitive files
-credentials.json
-*.pem
-*.key
-
-# Build artifacts
-dist/
-build/
-
-# Temporary files
-*.tmp
-*.temp