@cchez/memory-mcp 1.0.0

package/skills/memory-search/SKILL.md

@@ -0,0 +1,156 @@
+---
+name: memory-search
+description: >
+  Search the memory mcp knowledge base when information might already be stored
+  there. Triggers when the agent needs context about team decisions,
+  coding rules, past discussions, project facts, or any question that could
+  be answered from prior learnings. Also triggers when the user asks to
+  "check memory", "look up", "do we have anything on", or "what do we know about".
+  Use BEFORE asking the user for context that might already be stored. If a
+  result is corrected by the user or contradicted by new evidence, hand off to
+  correct_memory so the stale record is superseded.
+---
+
+# Memory Search Skill
+
+## Purpose
+
+Before asking the user for context, check the knowledge base. This avoids
+re-explaining things the system already knows, and surfaces relevant rules,
+decisions, and facts that should inform the current work.
+
+**Announce at start:** "Checking memory for relevant context."
+
+---
+
+## When to Trigger
+
+**Automatic triggers (invoke without being asked):**
+- Starting work on a feature or bug fix — check for relevant coding rules
+- Discussing architecture — check for prior decisions
+- Mentioning a team, project, or integration name — check for facts and context
+- A question arises that sounds like "we've probably figured this out before"
+
+**Manual triggers (user explicitly asks):**
+- "Check memory for X"
+- "Do we have anything on X"
+- "What do we know about X"
+- "Look up X in the knowledge base"
+
+**Do NOT trigger when:**
+- The question is clearly general knowledge (not project-specific)
+- Memory was already searched this session for the same topic
+- The user is asking to *save* something (use memory-save instead)
+
+---
+
+## Step 1 — Identify Search Intent
+
+Determine what to search for based on context:
+
+| Situation | Search query direction |
+|---|---|
+| Writing code in a specific domain | "coding rules constraints [domain]" |
+| Architecture question | "decision [component/system name]" |
+| Team process question | "team process [topic]" |
+| Integration with external system | "[system name] integration configuration" |
+| Error or known issue | "[error/symptom] known issue workaround" |
+
+Form 1–2 focused queries. Broad queries return noise; specific queries return signal.
+
+---
+
+## Step 2 — Choose Collections and Filters
+
+Pick the right scope:
+
+```
+coding rules, constraints, architecture decisions
+  → collections: ["coding"]
+  → memory_type: "rule" or "decision"
+
+team discussions, Slack decisions, project facts
+  → collections: ["workspace"]
+  → memory_type: "fact" or "summary"
+
+not sure / cross-cutting topic
+  → collections: ["coding", "workspace"]  (default — searches both)
+```
+
+Set `score_threshold: 0.5` by default to filter noise. Raise to `0.65` if too many results come back. Lower to `0.4` only if nothing is found.
+
+---
+
+## Step 3 — Execute Search
+
+Call `search_memory` with:
+- `query`: focused natural language query from Step 1
+- `collections`: chosen in Step 2
+- `limit`: 5 (default); raise to 10 if the topic is broad
+- `score_threshold`: 0.5
+- `memory_type`: add if you know the type, omit otherwise
+- `tags`: add if you know a relevant tag, omit otherwise
+
+Use the default `mode: "hybrid"` unless you have a specific reason not to.
+For exact identifiers, error messages, ticket IDs, or class names, use
+`mode: "keyword"` or keep hybrid and include the exact term in `query`.
+For audit/debugging of old corrections, set `include_inactive: true`.
+
+If the first search returns nothing useful, try once more with:
+- A rephrased query (different vocabulary, not just synonyms)
+- A lower `score_threshold` (0.4)
+- Broader `collections` (drop the collection filter)
+
+Do not search more than twice per topic without finding something — absence
+of results is itself useful signal ("we haven't recorded this yet").
+
+---
+
+## Step 4 — Interpret and Apply Results
+
+For each result returned:
+
+1. **Check the score**: below 0.5 = weak match, treat with caution
+2. **Check `memory_type`**:
+   - `rule` → this is a constraint, follow it
+   - `decision` → this was decided, don't relitigate without reason
+   - `fact` → current state of affairs, may be outdated
+   - `summary` → background context, use as backdrop
+   - `preference` → user/team preference, apply unless overridden
+3. **Check `created_at`**: facts older than 3 months may be stale — flag to user
+4. **Check lifecycle fields** if present:
+  - `status: active` → use normally
+  - `status: superseded` / `deprecated` → do not apply unless explicitly auditing history
+  - `superseded_by` → prefer the newer memory when available
+
+**Apply the results directly to your work.** Don't just summarise them back
+to the user — use them to inform your next action, code, or recommendation.
+
+---
+
+## Step 5 — Surface to User (only when relevant)
+
+If a result is directly actionable or changes your approach, mention it briefly:
+
+> "Found a relevant rule in memory: [one-line summary]. Applying that now."
+
+If results are background context (not immediately actionable), apply silently.
+
+If nothing was found, only mention it if the user explicitly asked to search,
+or if the absence of a rule/decision is itself significant:
+
+> "No prior decisions found on this. We're making a fresh call."
+
+If the user corrects a result, or you confirm the result is stale, call
+`correct_memory` with the old ID/collection and corrected standalone content.
+Do not ask the user to manually delete stale memories.
+
+---
+
+## Self-Check Before Finishing
+
+- [ ] Did the search results influence the work (code, recommendation, answer)?
+- [ ] Were stale facts (>3 months) flagged to the user?
+- [ ] If a result was corrected or contradicted, did you trigger `correct_memory`?
+- [ ] If nothing was found, was that noted where it matters?
+- [ ] Was search limited to ≤2 attempts per topic?