@basicmemory/openclaw-basic-memory 0.1.2 → 0.1.4

package/skills/memory-ingest/SKILL.md

@@ -0,0 +1,309 @@
+---
+name: memory-ingest
+description: "Process unstructured external input (meeting transcripts, conversation logs, pasted documents) into structured Basic Memory entities. Extracts entities, searches for existing matches, proposes new entities with approval, creates notes with observations and relations, and captures action items."
+---
+
+# Memory Ingest
+
+Turn raw, unstructured input into structured Basic Memory entities. Meeting transcripts, conversation logs, pasted documents, email threads — anything with information worth preserving gets parsed, cross-referenced against existing knowledge, and written as proper notes.
+
+## When to Use
+
+- User pastes a meeting transcript or conversation log
+- User says "process these notes" or "add this to Basic Memory"
+- User pastes a document, article, or email for knowledge extraction
+- Any time raw external text needs to become structured knowledge
+
+## Workflow Overview
+
+```
+1. Parse raw input           → identify structure, extract key info
+2. Extract entities          → people, orgs, topics, action items
+3. Search existing entities  → multi-variation queries
+4. Research new entities     → optional web research (see memory-research)
+5. Present entity proposal   → get approval before creating
+6. Create source note        → verbatim content + observations + relations
+7. Create approved entities  → structured notes for each new entity
+8. Extract action items      → follow-ups and commitments
+```
+
+## Step 1: Parse Raw Input
+
+Read the pasted content and identify its structure:
+
+- **Format**: Meeting transcript, email thread, conversation log, article, freeform notes
+- **Date**: When this happened (extract from content or ask)
+- **Participants**: Who was involved (names, roles, organizations)
+- **Sections**: Any existing structure (headings, speaker labels, timestamps)
+
+Don't rewrite or summarize the source content. Preserve it verbatim in the note — you'll add structured observations alongside it.
+
+## Step 2: Extract Entities
+
+Scan the content for entities worth tracking in the knowledge graph:
+
+| Entity Type | Signals |
+|-------------|---------|
+| **Person** | Names with roles, titles, or affiliations mentioned |
+| **Organization** | Company names, agencies, institutions |
+| **Topic/Concept** | Technical domains, methodologies, standards discussed substantively |
+| **Action Item** | Commitments, deadlines, "I'll do X by Y" statements |
+
+**Infer type from context.** If someone is introduced as "CTO of Acme Corp", that's both a Person and an Organization entity. If a technology is discussed in depth, it might warrant a Concept entity.
+
+**Exclude noise.** Not every name mentioned is worth an entity. Filter for:
+- People with substantive roles or interactions (not passing mentions)
+- Organizations discussed in business/technical context
+- Topics with enough detail to warrant their own note
+
+## Step 3: Search Existing Entities
+
+For each extracted entity, search Basic Memory with multiple query variations:
+
+```python
+# Person — try full name, last name
+search_notes(query="Sarah Chen")
+search_notes(query="Chen")
+
+# Organization — try full name, abbreviation, acronym
+search_notes(query="National Renewable Energy Laboratory")
+search_notes(query="NREL")
+
+# Topic — try the full term and keywords
+search_notes(query="edge computing")
+search_notes(query="edge inference")
+```
+
+Classify each entity as:
+- **Existing** — found in Basic Memory. Will link to it with `[[wiki-link]]`.
+- **Proposed** — not found. Will propose creation pending approval.
+
+## Step 4: Research New Entities (Optional)
+
+For proposed entities where more context would be valuable, do a brief web search (2-3 queries max per entity):
+
+- **Organizations**: What they do, size, public/private, key products
+- **People**: Current role, background, expertise
+- **Topics**: Brief definition, relevance
+
+Use hedging language ("appears to be", "estimated", "based on public information"). Never fabricate details.
+
+This step is optional — skip it if the source material provides enough context, or if the user is in a hurry. See the **memory-research** skill for deeper research workflows.
+
+## Step 5: Present Entity Proposal
+
+Before creating anything, present what you found and what you'd like to create:
+
+```
+Entities found in Basic Memory:
+  - [[Sarah Chen]] (Person — existing)
+  - [[Acme Corp]] (Organization — existing)
+
+Proposed new entities:
+  - Jordan Rivera (Person — VP Engineering at NovaTech, mentioned as project lead)
+  - NovaTech (Organization — SaaS platform, Series B, discussed as integration partner)
+  - Federated Learning (Concept — core technical topic of the discussion)
+
+Approve all / select individually / skip entity creation?
+```
+
+Include enough context with each proposed entity for the user to make a quick decision.
+
+## Step 6: Create the Source Note
+
+Create the primary note for the ingested content. This is the "record of what happened" — it preserves the raw material and adds structured metadata.
+
+### Meeting / Conversation Note
+
+```python
+write_note(
+  title="NovaTech Meeting - Jordan Rivera - Feb 22, 2026",
+  directory="meetings/2026",
+  note_type="meeting",
+  tags=["meeting", "novatech", "federated-learning"],
+  metadata={"date": "2026-02-22"},
+  content="""
+# NovaTech Meeting - Jordan Rivera - Feb 22, 2026
+
+Brief one-sentence summary of what this meeting was about.
+
+## Transcript
+[Preserve all source content verbatim — do not summarize or rewrite]
+
+## Observations
+- [opportunity] NovaTech interested in integration partnership
+- [insight] Their platform handles 10K concurrent sessions, relevant to our scale needs
+- [next_step] Send technical spec document by Friday
+- [sentiment] Strong enthusiasm from their engineering team
+- [decision] Agreed to start with a proof-of-concept integration
+
+## Relations
+- attended [[Jordan Rivera]]
+- with [[NovaTech]]
+- discussed [[Federated Learning]]
+- follow_up [[Send NovaTech Technical Spec]]
+"""
+)
+```
+
+### Document / Article Note
+
+```python
+write_note(
+  title="Edge Computing Architecture Whitepaper",
+  directory="references",
+  note_type="reference",
+  tags=["edge-computing", "architecture", "reference"],
+  metadata={"source": "https://example.com/whitepaper.pdf", "date_ingested": "2026-02-22"},
+  content="""
+# Edge Computing Architecture Whitepaper
+
+## Source Content
+[Preserve relevant content — for long documents, include key sections rather than the entire text]
+
+## Observations
+- [key_finding] Latency drops 40% with edge inference vs cloud-only
+- [technique] Model sharding across heterogeneous edge nodes
+- [limitation] Requires minimum 8GB RAM per edge node
+
+## Relations
+- relates_to [[Edge Computing]]
+- relates_to [[Model Optimization]]
+"""
+)
+```
+
+### Observation Categories
+
+Use categories that capture the nature of the information. Common categories for ingested content:
+
+| Category | Use For |
+|----------|---------|
+| `opportunity` | Business or collaboration opportunities identified |
+| `decision` | Decisions made or agreed upon |
+| `insight` | Non-obvious understanding gained |
+| `next_step` | Concrete action items or follow-ups |
+| `sentiment` | Enthusiasm, concerns, hesitations expressed |
+| `risk` | Risks or concerns identified |
+| `requirement` | Requirements or constraints discovered |
+| `key_finding` | Important facts from reference material |
+| `technique` | Methods, approaches, or patterns described |
+| `context` | Background information that may be useful later |
+
+Invent categories as needed — these are suggestions, not a fixed list.
+
+## Step 7: Create Approved Entities
+
+For each entity the user approved, create a structured note. Match the entity type to an appropriate template.
+
+### Person
+
+```python
+write_note(
+  title="Jordan Rivera",
+  directory="people",
+  note_type="person",
+  tags=["person", "novatech", "engineering"],
+  content="""
+# Jordan Rivera
+
+## Overview
+VP of Engineering at NovaTech. Met during integration partnership discussion.
+
+## Background
+[Role, expertise, context from meeting + any web research]
+
+## Observations
+- [role] VP Engineering at NovaTech
+- [expertise] Distributed systems, federated learning
+- [met] 2026-02-22 during integration discussion
+
+## Relations
+- works_at [[NovaTech]]
+- discussed_in [[NovaTech Meeting - Jordan Rivera - Feb 22, 2026]]
+"""
+)
+```
+
+### Organization
+
+```python
+write_note(
+  title="NovaTech",
+  directory="organizations",
+  note_type="organization",
+  tags=["organization", "saas", "integration-partner"],
+  content="""
+# NovaTech
+
+## Overview
+SaaS platform company. Series B stage.
+[Additional context from meeting + web research]
+
+## Products & Services
+[What they offer, if discussed or researched]
+
+## Observations
+- [stage] Series B, ~200 employees
+- [relevance] Potential integration partner for our platform
+- [first_contact] 2026-02-22
+
+## Relations
+- employs [[Jordan Rivera]]
+- discussed_in [[NovaTech Meeting - Jordan Rivera - Feb 22, 2026]]
+"""
+)
+```
+
+### Concept / Topic
+
+```python
+write_note(
+  title="Federated Learning",
+  directory="concepts",
+  note_type="concept",
+  tags=["concept", "machine-learning", "distributed-systems"],
+  content="""
+# Federated Learning
+
+## Overview
+[Brief description of the concept from the discussion context]
+
+## Observations
+- [definition] Machine learning approach where models train across decentralized data sources
+- [relevance] Core technique discussed in NovaTech integration
+
+## Relations
+- discussed_in [[NovaTech Meeting - Jordan Rivera - Feb 22, 2026]]
+"""
+)
+```
+
+Adapt templates to your domain. The key elements are: type and tags as parameters, an overview section, observations with categories, and relations linking back to the source.
+
+## Step 8: Extract Action Items
+
+Review the source content for commitments and follow-ups:
+
+```
+Action Items:
+  - Send NovaTech technical spec document by Friday (your commitment)
+  - Jordan will share their API documentation by next week (their commitment)
+
+Follow-Up Reminders:
+  - 1 week: Check if Jordan sent API docs
+  - 2 weeks: Schedule follow-up call to discuss POC scope
+```
+
+If using the **memory-tasks** skill, create Task notes for your action items. Otherwise, capture them as observations in the source note.
+
+## Guidelines
+
+- **Preserve source content verbatim.** The original text is the ground truth. Structure and observations are your interpretation layered on top.
+- **Search before creating.** Always check if entities already exist (see memory-notes search-before-create pattern). Update existing entities with new information rather than creating duplicates.
+- **Get approval for new entities.** Present proposed entities and let the user decide which to create. Don't silently populate the knowledge graph.
+- **Infer, don't interrogate.** Extract entity types and relationships from context. Only ask the user when genuinely ambiguous.
+- **Be selective about entities.** Not every name mentioned deserves its own note. Focus on entities the user will want to reference again.
+- **Use hedging for researched info.** Web research supplements — don't present it as fact. "Appears to be", "estimated", "based on public information".
+- **Link everything back.** Every created entity should relate back to the source note. The source note should link to all entities discussed.
+- **Prose and observations together.** Notes work best with both narrative context and structured observations. Prose gives meaning and tells the story; observations make individual facts searchable. Use the body for context, then distill key facts into categorized observations.

package/skills/memory-lifecycle/SKILL.md

@@ -0,0 +1,182 @@
+---
+name: memory-lifecycle
+description: "Manage entity status transitions in Basic Memory: archive completed work, move notes between status folders, update frontmatter, and handle edge cases. Use when marking items complete, archiving old entities, or managing any folder-based status workflow."
+---
+
+# Memory Lifecycle
+
+Manage how entities move through status stages in Basic Memory. The core principle: **archive, never delete.** Completed work is valuable context — move it out of the active view, but keep it in the knowledge graph.
+
+## When to Use
+
+- User says something is "done", "finished", "completed", "submitted", "missed", or "cancelled"
+- Moving entities between status folders (active → archive, pipeline → active, etc.)
+- Reverting a mistaken completion
+- Periodic cleanup of stale active items
+
+## Core Principle: Archive, Never Delete
+
+Deleting a note removes it from the knowledge graph — all its observations, relations, and history disappear. Archiving preserves everything while signaling the entity is no longer active.
+
+```
+# Good — entity stays in the knowledge graph
+move_note → active/ to archive/
+
+# Bad — knowledge is lost
+delete_note
+```
+
+The only exception: notes created by mistake (typos, true duplicates) can be deleted.
+
+## Folder Conventions
+
+Organize entities by status using folders. The exact folder names depend on your domain, but follow a consistent pattern:
+
+```
+entities/
+  active/          # Currently relevant, in-progress
+  archive/         # Completed, no longer active, but worth keeping
+  pipeline/        # Future items, not yet started
+```
+
+For tasks specifically:
+
+```
+tasks/
+  active/          # Work in progress
+  completed/       # Finished work
+```
+
+For any entity type with a clear lifecycle:
+
+```
+[type]/
+  active/          # Current
+  [end-state]/     # Whatever "done" means for this type
+```
+
+Pick folder names that match your domain. The pattern matters more than the specific names.
+
+## Status Detection
+
+When the user mentions completion or status change, extract the intent:
+
+| Signal | Status | Action |
+|--------|--------|--------|
+| "finished", "done", "completed", "shipped" | Complete | Move to archive/completed folder |
+| "submitted", "sent", "delivered" | Complete | Move to archive/completed folder |
+| "missed", "passed", "skipped", "expired" | Missed | Move to archive or missed folder |
+| "cancelled", "abandoned", "killed" | Cancelled | Move to archive folder |
+| "paused", "on hold", "deferred" | Paused | Update frontmatter status, keep in place |
+| "restarting", "reopening", "reviving" | Reactivate | Move back to active folder |
+
+## Workflow
+
+### 1. Find the Entity
+
+Search Basic Memory with multiple variations to locate the entity:
+
+```python
+search_notes(query="quarterly report")
+search_notes(query="Q1 report")
+```
+
+If multiple matches come back, present options and ask which one.
+
+If no match is found, ask for clarification — don't guess.
+
+### 2. Move the File
+
+Use `move_note` to relocate the entity to the appropriate status folder:
+
+```python
+move_note(
+  identifier="tasks/active/quarterly-report",
+  destination_path="tasks/completed/quarterly-report.md"
+)
+```
+
+The permalink stays the same, so all existing `[[wiki-links]]` and `memory://` URLs continue to resolve.
+
+### 3. Update Frontmatter
+
+After moving, update the status in frontmatter to match:
+
+```python
+edit_note(
+  identifier="quarterly-report",
+  operation="find_replace",
+  find_text="status: active",
+  content="status: completed"
+)
+```
+
+If there's a completion date field, set it:
+
+```python
+edit_note(
+  identifier="quarterly-report",
+  operation="find_replace",
+  find_text="completed:",
+  content="completed: 2026-02-22"
+)
+```
+
+### 4. Confirm
+
+Report what was done concisely:
+
+```
+Marked complete: Quarterly Report
+  Moved to: tasks/completed/quarterly-report.md
+  Status: completed
+```
+
+## Edge Cases
+
+### Already Archived
+
+If the entity is already in an archive/completed folder, notify the user:
+
+> "Quarterly Report is already in tasks/completed/. Want me to update anything on it?"
+
+### Partial Completion
+
+Sometimes only part of an entity is done. Don't move it — instead, update observations or status notes within the entity to reflect partial progress.
+
+### Revert / Reactivate
+
+If something was archived by mistake, move it back:
+
+```python
+move_note(
+  identifier="tasks/completed/quarterly-report",
+  destination_path="tasks/active/quarterly-report.md"
+)
+
+edit_note(
+  identifier="quarterly-report",
+  operation="find_replace",
+  find_text="status: completed",
+  content="status: active"
+)
+```
+
+### Status Without Movement
+
+Some status changes don't require a folder move — "paused" or "blocked" items often stay in `active/` with just a frontmatter update. Reserve folder moves for terminal or major state transitions.
+
+## Relationship to Other Skills
+
+- **memory-tasks**: Tasks are a specific lifecycle case. This skill covers the general pattern; memory-tasks covers task-specific fields (steps, current_step, context).
+- **memory-notes**: Use search-before-create (from memory-notes) to find the entity before transitioning it.
+- **memory-defrag**: Periodic defrag can identify stale active items that should be archived.
+
+## Guidelines
+
+- **Archive, never delete.** The knowledge graph benefits from historical context.
+- **Move first, then update frontmatter.** This order ensures the file is in the right place even if the edit step fails.
+- **Permalinks survive moves.** Links to the entity keep working after a `move_note`.
+- **Be concise in confirmations.** The user knows their system — just report what changed.
+- **Ask when ambiguous.** If multiple entities match or the target folder isn't clear, ask rather than guess.
+- **Batch operations are fine.** If the user says "archive all completed tasks", find them all, confirm the list, then move them in sequence.

package/skills/memory-metadata-search/SKILL.md

@@ -16,16 +16,9 @@ Find notes by their structured frontmatter fields instead of (or in addition to)
 - **Tag-based filtering** — find notes tagged with specific frontmatter tags
 - **Schema-aware queries** — filter by nested schema fields using dot notation
 
-## Tool
+## The Tool
 
-Use the `search_notes` tool with the optional `metadata_filters`, `tags`, and `status` parameters.
-
-| Parameter | Type | Description |
-|-----------|------|-------------|
-| `query` | string | Text search query (can be empty for filter-only searches) |
-| `metadata_filters` | object | Filter by frontmatter fields (see filter syntax below) |
-| `tags` | string[] | Filter by frontmatter tags (all must match) |
-| `status` | string | Filter by frontmatter status field |
+All metadata searching uses `search_notes`. Pass filters via `metadata_filters`, or use the `tags` and `status` convenience shortcuts. Omit `query` (or pass `None`) for filter-only searches.
 
 ## Filter Syntax
 
@@ -87,71 +80,52 @@ Numeric values use numeric comparison; strings use lexicographic comparison.
 - `$in` and array-contains require non-empty lists
 - `$between` requires exactly `[min, max]`
 
-## Examples
-
-### Metadata-only search (empty query)
-
-```
-search_notes(query="", metadata_filters={"status": "in-progress", "type": "spec"})
-```
-
-### Text search narrowed by metadata
+## Using `search_notes` with Metadata
 
-```
-search_notes(query="authentication", metadata_filters={"status": "draft"})
-```
+Pass `metadata_filters`, `tags`, or `status` to `search_notes`. Omit `query` for filter-only searches, or combine text and filters together.
 
-### Filter by tags
+```python
+# Filter-only — find all notes with a given status
+search_notes(metadata_filters={"status": "in-progress"})
 
-```
-search_notes(query="", tags=["security", "oauth"])
-```
+# Filter-only — high-priority specs in a specific project
+search_notes(
+    metadata_filters={"type": "spec", "priority": {"$in": ["high", "critical"]}},
+    project="research",
+    page_size=10,
+)
 
-### Filter by status shortcut
+# Filter-only — notes with confidence above a threshold
+search_notes(metadata_filters={"confidence": {"$gt": 0.7}})
 
-```
-search_notes(query="planning", status="active")
-```
+# Convenience shortcuts for tags and status
+search_notes(status="active")
+search_notes(tags=["security", "oauth"])
 
-### Combined text + metadata + tags
+# Text search narrowed by metadata
+search_notes("authentication", metadata_filters={"status": "draft"})
 
-```
+# Mix text, tag shortcut, and advanced filter
 search_notes(
-    query="oauth flow",
-    metadata_filters={"confidence": {"$gt": 0.7}},
+    "oauth flow",
     tags=["security"],
-    status="in-progress",
-)
-```
-
-### High-priority notes in a specific project
-
-```
-search_notes(
-    query="",
-    metadata_filters={"priority": {"$in": ["high", "critical"]}},
-    project="research",
-    limit=10,
+    metadata_filters={"confidence": {"$gt": 0.7}},
 )
 ```
 
-### Numeric range query
-
-```
-search_notes(query="", metadata_filters={"score": {"$between": [0.3, 0.8]}})
-```
+**Merging rules:** `tags` and `status` are convenience shortcuts merged into `metadata_filters` via `setdefault`. If the same key exists in `metadata_filters`, the explicit filter wins.
 
 ## Tag Search Shorthand
 
 The `tag:` prefix in a query converts to a tag filter automatically:
 
-```
+```python
 # These are equivalent:
-search_notes(query="tag:tier1")
-search_notes(query="", tags=["tier1"])
+search_notes("tag:tier1")
+search_notes("", tags=["tier1"])
 
 # Multiple tags (comma or space separated) — all must match:
-search_notes(query="tag:tier1,alpha")
+search_notes("tag:tier1,alpha")
 ```
 
 ## Example: Custom Frontmatter in Practice
@@ -180,29 +154,29 @@ confidence: 0.85
 
 Queries that find it:
 
-```
+```python
 # By status and type
-search_notes(query="", metadata_filters={"status": "in-progress", "type": "spec"})
+search_notes(metadata_filters={"status": "in-progress", "type": "spec"})
 
 # By numeric threshold
-search_notes(query="", metadata_filters={"confidence": {"$gt": 0.7}})
+search_notes(metadata_filters={"confidence": {"$gt": 0.7}})
 
 # By priority set
-search_notes(query="", metadata_filters={"priority": {"$in": ["high", "critical"]}})
+search_notes(metadata_filters={"priority": {"$in": ["high", "critical"]}})
 
 # By tag shorthand
-search_notes(query="tag:security")
+search_notes("tag:security")
 
 # Combined text + metadata
-search_notes(query="OAuth", metadata_filters={"status": "in-progress"})
+search_notes("OAuth", metadata_filters={"status": "in-progress"})
 ```
 
 ## Guidelines
 
-- **Use metadata filters for structured queries.** If you're looking for notes by a known field value (status, priority, type), metadata filters are more precise than text search.
+- **Use metadata search for structured queries.** If you're looking for notes by a known field value (status, priority, type), metadata filters are more precise than text search.
 - **Use text search for content queries.** If you're looking for notes *about* something, text search is better. Combine both when you need precision.
 - **Custom fields are free.** Any YAML key you put in frontmatter becomes queryable — no schema or configuration required.
 - **Multiple filters are AND.** `{"status": "active", "priority": "high"}` requires both conditions.
-- **Use empty query for filter-only searches.** Pass `query=""` with `metadata_filters` when you only need structured filtering.
+- **Omit `query` for filter-only searches.** `search_notes(metadata_filters={"status": "active"})` works without a text query.
 - **Dot notation for nesting.** Access nested YAML structures with dots: `{"schema.version": "2"}` queries the `version` key inside a `schema` object.
-- **Tags and status are convenient shortcuts.** Use the dedicated `tags` and `status` parameters for common fields, or `metadata_filters` for anything else.
+- **Tags shortcut is convenient but limited.** `tags` and `status` are sugar for common fields. For anything else, use `metadata_filters` directly.