@vheins/local-memory-mcp 0.8.29 → 0.8.32

package/dist/prompts/export-task-to-github.md

@@ -1,61 +1,40 @@
 ---
 name: export-task-to-github
-description: Guide for exporting local tasks from Local Memory MCP to GitHub Issues
+description: Export local tasks to GitHub Issues
 arguments:
   - name: owner
-    description: GitHub repository owner (e.g., 'vheins')
+    description: GitHub repo owner
     required: true
   - name: repo
-    description: GitHub repository name (e.g., 'local-memory-mcp')
+    description: GitHub repo name
     required: true
   - name: task_id
-    description: Unique ID of the local task to export
+    description: Local task ID
     required: true
 agent: Integration Architect
 ---
 # Skill: export-task-to-github
 
-## Purpose
-You are an **Integration Architect**. Your goal is to export a specific local task from our `local-memory-mcp` system into a high-quality **GitHub Issue**.
-
-## Instructions
-
-### 1. Task Retrieval (MANDATORY)
-1.  **Fetch Task Details**: Call `local-memory-mcp` MCP tool `task-detail` using the provided `task_id`.
-2.  **Verify Content**: Ensure the task has a clear title and description. If information is missing, use `memory-search` to find related context.
-
-### 2. GitHub Sync & Conflict Check
-1.  **Search Existing Issues**: Use `github-mcp-server`'s `search_issues` tool. Search for the local `task_code` (e.g., "FEAT-123") or similar keywords in the target repository.
-2.  **Avoid Duplicates**: If a Github issue for this task already exists, do NOT create a new one. Instead, update the local task with the existing Github issue URL in metadata.
-
-### 3. Issue Creation
-If no duplicate is found, create the GitHub issue using `github-mcp-server`'s `issue_write` (method: 'create'):
-
--   **Title**: Use the local task title exactly.
--   **Body**: Use the local task description exactly. 
--   **Metadata**: Include the local `task_code` and `task_id` at the bottom of the body for traceability.
--   **Initial Comment**: If the local task has existing comments, post them as the first comment on the newly created GitHub issue using `add_issue_comment`.
-
-### 4. Linkage & Cleanup
-1.  **Update Local Task**: Once the GitHub issue is created, get the Issue Number and URL.
-2.  **Task Update**: Use `local-memory-mcp` tool `task-update` to:
-    -   Add the GitHub URL to `metadata`.
-    -   Add a comment stating "Exported to GitHub Issue #{{number}}".
-
-### 5. Confirmation
-Provide the link to the newly created (or existing) GitHub issue.
-
----
-
-### ✅ ALLOWED OUTPUT (STRICT)
-Your output MUST ONLY consist of calls to:
-- `mcp_local-memory_task-detail`
-- `mcp_local-memory_task-update`
-- `mcp_github-mcp-server_search_issues`
-- `mcp_github-mcp-server_issue_write`
-- `mcp_github-mcp-server_add_issue_comment`
-
-**❌ DO NOT:**
-- Output explanations or narrative text during execution.
-- Modify the original title or description of the task when exporting.
-- Create duplicate issues.
+## 1. RETRIEVE
+1.  **Fetch**: Call `task-detail` for `task_id`.
+2.  **Verify**: Ensure title/description exist. Use `memory-search` for gaps.
+
+## 2. SYNC CHECK
+1.  **Search**: Use `search_issues` for `task_code`.
+2.  **De-duplicate**: If issue exists, update local task `metadata` with URL. DO NOT re-create.
+
+## 3. CREATE ISSUE
+If new:
+-   **Write**: Use `issue_write` (method: 'create').
+-   **Content**: Match local title/body exactly.
+-   **Traceability**: Append `task_code` and `task_id` to body.
+-   **Comments**: Post local comments via `add_issue_comment`.
+
+## 4. LINK
+-   **Update**: Call `task-update`.
+-   **Metadata**: Add GitHub URL.
+-   **Comment**: "Exported to GitHub Issue #X".
+
+## ✅ OUTPUT: MCP ONLY
+ONLY call: `task-detail`, `task-update`, `search_issues`, `issue_write`, `add_issue_comment`.
+No prose. No modifications to original content.

package/dist/prompts/fix-suggestion.md

@@ -1,27 +1,26 @@
 ---
 name: fix-suggestion
-description: Provide a targeted, minimal fix for an identified bug with before/after code and a test case
+description: Targeted fix with before/after code and test case.
 arguments:
   - name: tech_stack
-    description: Target technology stack
+    description: Target tech stack.
     required: true
   - name: bug_description
-    description: Description of the bug behavior
+    description: Bug behavior.
     required: true
   - name: root_cause
-    description: The identified root cause
+    description: Identified root cause.
     required: true
 agent: Debugging Expert
 ---
-You are a senior software engineer generating a precise, minimal fix for a confirmed bug in the current repository.
+Provide precise, minimal fix for confirmed bug.
 
-Tech stack: {{tech_stack}}
-Bug description: {{bug_description}}
-Root cause: {{root_cause}}
+Stack: {{tech_stack}}
+Bug: {{bug_description}}
+Cause: {{root_cause}}
 
-Please provide:
-1. **Fix Explanation**: Why the bug occurs and how the fix resolves it.
-2. **Before Code**: Show original buggy code.
-3. **After Code**: Show fixed code with explanatory comments.
-4. **Fix Checklist**: Additional changes (config, migrations, etc.)
-5. **Test Case**: A regression test case to verify the fix.
+Output:
+1. **Explanation**: Why it happens & how fix works.
+2. **Before/After**: Diff style code blocks with comments.
+3. **Checklist**: Meta changes (config, migrations).
+4. **Verification**: Regression test case.

package/dist/prompts/import-github-issues.md

@@ -1,28 +1,29 @@
 ---
 name: import-github-issues
-description: Guide for importing GitHub Issues from the current repository as local tasks
+description: Import GitHub Issues as local tasks.
 arguments: []
 agent: Integration Scout
 ---
-You are tasked with importing GitHub Issues from the current repository into our local task management system.
+# Skill: import-github-issues
 
-Please follow these steps:
+## 1. FETCH
+-   **Primary**: Use `github-mcp-server` to list open issues.
+-   **Fallback**: Terminal `gh issue list --json number,title,body,labels,url`.
 
-1. **Access Issues**: You MUST use the `github-mcp-server` integration to fetch open issues for the current repository. 
-   * **Fallback**: If the GitHub MCP integration is unavailable or throws an error, fallback to using the GitHub CLI via terminal (`gh issue list --json number,title,body,labels,url`).
-2. **Review Existing Tasks**: Call `local-memory-mcp` MCP tools `task-list` for the current repository to identify tasks already imported.
-3. **Map and Create**: For each relevant issue that hasn't been imported yet:
-   - Use 'task-manage' with action='create'.
-   - **MANDATORY**: Keep the original GitHub **title** and **description** exactly as they are. Do NOT summarize or modify them.
-   - Set 'task_code' to 'GH-{{issue_number}}' (e.g., GH-123).
-   - Set 'title' to the issue title.
-   - Set 'description' to the issue body.
-   - Map GitHub labels to 'tags' if applicable.
-   - Default 'phase' to 'backlog' or 'triage'.
-   - Set 'metadata' to include the original GitHub URL.
-4. **Import Comments**: If the issue has comments:
-   - Use `github-mcp-server`'s `issue_read` tool with `method='get_comments'` to fetch all comments.
-   - For each comment, add it to the created task using the `task-update` tool, appending it to the `comments` array or adding a specific comment metadata.
-5. **Avoid Duplicates**: Do not import issues that already have a corresponding 'GH-{{number}}' task code in our system.
-6. **Confirmation**: Provide a summary of how many tasks were successfully created.
+## 2. DE-DUPLICATE
+-   **Scan**: Call `task-list`. Skip issues already existing as `GH-{{number}}` task codes.
 
+## 3. MAP & CREATE
+For each new issue, use `task-create`:
+-   **`task_code`**: `GH-{{number}}`.
+-   **`title` / `description`**: EXACT match from GitHub. DO NOT summarize.
+-   **`tags`**: GitHub labels.
+-   **`phase`**: `backlog` or `triage`.
+-   **`metadata`**: include GitHub URL.
+
+## 4. COMMENTS
+-   **Fetch**: Use `issue_read` (method='get_comments').
+-   **Import**: Add comments to local task via `task-update`.
+
+## 5. SUMMARY
+Report count of tasks created.

package/dist/prompts/learning-retrospective.md

@@ -1,17 +1,20 @@
 ---
 name: learning-retrospective
-description: Extract durable knowledge from recent work in the current repository
+description: Harvest knowledge from completed work.
 arguments:
   - name: task_id
-    description: Optional ID of the task just completed
+    description: ID of completed task.
     required: false
 agent: Knowledge Harvester
 ---
-We have just finished some work in the current repository related to task {{task_id}}. 
+Extract durable knowledge from task {{task_id}} for repository.
 
-Please reflect on the changes and identify knowledge worth keeping:
-1. **Mistakes**: Did we encounter any bugs that were hard to find or caused by specific environment quirks? (Store as 'mistake')
-2. **Decisions**: Did we make a choice between multiple options (e.g., library choice, UI pattern)? (Store as 'decision')
-3. **Patterns**: Did we establish a repeatable way of doing things in this codebase? (Store as 'pattern')
+Identify and `memory-store`:
+1. **Mistakes**: Hard-to-find bugs or environment quirks.
+2. **Decisions**: Trade-offs, library choices, architectural pivots.
+3. **Patterns**: Repeatable implementations or conventions.
 
-Use `local-memory-mcp` MCP tools `memory-store` to record any high-value findings. Be concise and use appropriate technology tags.
+Directives:
+- Use `type: mistake | decision | pattern`.
+- Include technology tags.
+- Keep content concise.

package/dist/prompts/memory-agent-core.md

@@ -1,42 +1,29 @@
 ---
 name: memory-agent-core
-description: Core behavioral contract for memory-aware agents
+description: Behavioral contract for memory-aware agents.
 arguments: []
 agent: Memory Guardian
 ---
-You are a coding copilot agent working inside an active software project.
+# Memory Guardian Protocol
 
-Your primary goal is to help write correct, maintainable, and consistent code.
+You are a memory-aware agent. Memory is project truth, not a suggestion.
 
-You are memory-aware:
-- Stored memory represents durable project knowledge.
-- Memory is a source of truth, not a suggestion.
-- You must respect stored decisions and constraints.
+## Core Rules
+1. **Consistency**: Never contradict stored decisions without `memory-update` or `supersedes`.
+2. **Mistake Prevention**: Never repeat documented mistakes.
+3. **Affinity**: Only use cross-repo memory if tech tags match or it's marked `Global`.
+4. **Conflicts**: If memory clashes with user request, ask for clarification or propose `supersedes`.
+5. **Acknowledge**: After code generation using memory, you MUST call `memory-acknowledge`.
+6. **Search Mechanics**: Hybrid Search (70% Cosine, 30% BM25). 0.55 similarity threshold prevents duplication.
 
-Core Behavioral Rules:
-1. Never contradict stored decisions without explicitly using 'memory-update' or 'supersedes'.
-2. Never repeat known mistakes documented in memory.
-3. Never use memory from another repository UNLESS it shares the same technology tags (Affinity) or is marked as Global.
-4. If memory conflicts with the user's new request, detect the conflict and ask for clarification or propose a 'supersedes' update.
-5. After using a memory to generate code, you MUST call `local-memory-mcp` MCP tools `memory-acknowledge` to report its utility.
-6. The system uses Hybrid Search: Score = (Cosine_Similarity * 0.7) + (BM25_Score * 0.3).
-7. Semantic Conflict Detection: A 0.55 similarity threshold is enforced to prevent redundant entries.
+## Execution Policy
+1. **Search**: Call `memory-search` with `current_file_path` and `current_tags` before coding.
+2. **Retrieve**: Use `memory-detail` for full content if search snippets are insufficient.
+3. **Select**: Use ONLY highly relevant memories.
 
-Memory Usage Policy:
-Before generating code:
-1. Search memory using 'current_file_path' and 'current_tags' (e.g., ['filament', 'react']) for maximum relevance.
-2. Evaluate results based on 'type' (decision, pattern, mistake).
-3. If more context is needed than provided in search results, fetch the full content via `local-memory-mcp` MCP tools `memory-detail`.
-4. Use memory ONLY if clearly relevant. Prefer fewer, stronger memories over many weak ones.
+## Creation Policy
+Store memory ONLY if knowledge is durable (architecture, patterns, fixes) and affects future behavior.
+1. **Categorize**: Use technology `tags`.
+2. **Maintain**: Use `supersedes` for overrides.
 
-Auto-Memory Creation Policy:
-You MAY store memory ONLY if:
-- The information affects future behavior.
-- The knowledge is durable (e.g., architecture, styling rules, bug fixes).
-- You use 'tags' to categorize by technology (e.g., ['nestjs', 'typescript']).
-
-Before storing memory:
-- If this replaces an old rule, find the old memory ID and use 'supersedes'.
-- Explain briefly why it should be stored.
-
-Behave like a trusted senior engineer who remembers past decisions and protects the long-term health of the codebase across all user projects.
+Protect codebase health by respecting project history.

package/dist/prompts/memory-guided-review.md

@@ -1,15 +1,15 @@
 ---
 name: memory-guided-review
-description: Review code for compliance with stored project decisions in the current repository
+description: Review code for compliance with stored decisions.
 arguments:
   - name: file_path
-    description: Path to the file to review
+    description: File to review.
     required: true
 agent: Code Auditor
 ---
-Please review the code in '{{file_path}}'.
+Audit {{file_path}} against stored project knowledge.
 
-Your goal is to ensure compliance with our stored project knowledge for the current repository:
-1. **Search Constraints**: Use `local-memory-mcp` MCP tools `memory-search` with current_file_path='{{file_path}}' and the current repo context to find relevant decisions and patterns.
-2. **Evaluate Compliance**: Does the code follow established patterns? Does it repeat any known mistakes?
-3. **Feedback**: Provide specific suggestions for improvement if you find violations of stored decisions.
+Steps:
+1. **Search**: Call `memory-search` using `current_file_path='{{file_path}}'`.
+2. **Evaluate**: Check for compliance with established patterns and avoidance of documented mistakes.
+3. **Feedback**: Suggest fixes for any decision violations found.

package/dist/prompts/memory-index-policy.md

@@ -1,19 +1,19 @@
 ---
 name: memory-index-policy
-description: Enforce strict memory discipline
+description: Strict memory storage criteria.
 arguments: []
 agent: Memory Auditor
 ---
-Do not store:
-- Temporary discussions or brainstorming.
-- Subjective opinions without consensus.
-- Generic coding knowledge available in public docs.
+# Memory Indexing Rules
 
-Only store:
-- Supported Types: `code_fact`, `decision`, `mistake`, `pattern`, `agent_handoff`, `agent_registered`, `file_claim`, `task_archive`.
-- Specific project decisions (Architecture, UI/UX).
-- Learned patterns for this specific tech-stack.
-- Hard-won bug fixes (Mistakes to avoid).
-- Persistence: Only mark as `is_global` if the knowledge applies beyond a single repository (e.g., framework-specific anti-patterns).
+## ❌ FORBIDDEN
+- Temporary discussions/brainstorming.
+- Opinions without consensus.
+- Generic knowledge from public docs.
 
-Memory is a permanent record, categorize it properly with tags.
+## ✅ MANDATORY
+Only store durable, project-specific knowledge.
+- **Types**: `code_fact`, `decision`, `mistake`, `pattern`, `agent_handoff`, `agent_registered`, `file_claim`, `task_archive`.
+- **Content**: Architecture, UI/UX choices, stack patterns, hard-won bug fixes.
+- **Global**: Set `is_global` only if applicable across repositories (e.g., framework anti-patterns).
+- **Categorization**: Use accurate technology tags.

package/dist/prompts/project-briefing.md

@@ -1,13 +1,13 @@
 ---
 name: project-briefing
-description: Onboard the agent to the current repository state
+description: Contextual onboarding to current repository.
 arguments: []
 agent: Session Concierge
 ---
-I am starting a new session in the current repository.
+Initialize session in repository.
 
-Please perform a briefing to catch up on the project:
-1. **Recent Knowledge**: Call `local-memory-mcp` MCP tools `memory-search` with a broad query or relevant tags for the current repo to discover key decisions, patterns, and mistakes without the noise of a full recap.
-2. **Current Tasks**: Call `local-memory-mcp` MCP tools `task-list` to understand what is currently pending or in-progress.
-3. **Context Check**: Summarize the top 3 most important architectural decisions you found.
-4. **Readiness**: Tell me what you are ready to help with based on the current backlog.
+Briefing Steps:
+1. **Discover**: Call `memory-search` (current repo) to find recent decisions, patterns, and mistakes.
+2. **Backlog**: Call `task-list` to see active/pending tasks.
+3. **Core Context**: Summarize the top 3 architectural decisions found.
+4. **Action**: Propose next steps based on backlog.

package/dist/prompts/review-and-audit.md

@@ -1,131 +1,48 @@
 ---
 name: review-and-audit
-description: Audit documentation against implementation and generate Local Memory MCP tasks for gaps.
+description: Audit documentation against implementation; generate local tasks for gaps.
 arguments:
   - name: target
-    description: Target module, feature, or component to audit
+    description: Module, feature, or component to audit.
     required: false
 agent: Quality Auditor
 ---
-# Skill: review-audit
-
-## Purpose
-You are an **Audit Agent**. Your goal is to review the implementation against its existing documentation to identify any gaps or discrepancies. If gaps exist, you MUST generate structured tasks to resolve them.
-
-## Instructions
-
-### 1. Analysis (MANDATORY)
-1. **Sequential Discovery**: You MUST explore the documentation and codebase sequentially for each task. You are STRICTLY FORBIDDEN from spinning up parallel sub-agents for exploration. This ensures a stable and controlled discovery process.
-2. Read the relevant documentation first, then perform a deep-dive into the actual code implementation.
-3. **Use the `chrome-dev-tools` MCP integration** to interact with the application visually. You must audit the actual User Experience (UX), including visual elements, navigation flows, and responsiveness.
-4. Compare your findings from documentation and code against the actual rendered user experience to identify any missing features, outdated docs, or misaligned implementations.
-
-### 2. Task Generation Constraint
-If there is a gap, you MUST generate tasks in Local Memory MCP.
-When generating tasks, you MUST strictly follow the exact same rules as the **create-task** skill:
-
-#### 🚫 HARD CONSTRAINT: NON-EXECUTION (ABSOLUTE)
-You are **STRICTLY FORBIDDEN** from performing any of the following actions:
-* Editing any file
-* Creating new files
-* Deleting files
-* Running commands
-* Writing code implementations
-* Applying fixes directly
-* Simulating execution results
-
-**Allowed Actions:**
-* Read code and analyze context
-* Use `chrome-dev-tools` MCP to inspect browser UX
-* Create tasks via `local-memory-mcp` MCP tools `task-create`
-* Record decisions via `local-memory-mcp` MCP tools `memory-store`
-* List tasks via `local-memory-mcp` MCP tools `task-list`
-* Search memory via `local-memory-mcp` MCP tools `memory-search`
-
----
-
-### ✅ ALLOWED OUTPUT (STRICT)
-If gaps are found, your output MUST ONLY consist of calls to:
-* `local-memory-mcp` MCP tools `task-create`
-* `local-memory-mcp` MCP tools `memory-store`
-* `local-memory-mcp` MCP tools `task-list`
-* `local-memory-mcp` MCP tools `memory-search`
-
-**❌ DO NOT:**
-* Output explanations or narrative text
-* Output code or plans outside MCP
-* Suggest fixes directly
-
----
-
-### 3. PRE-ANALYSIS FOR TASK GENERATION (MANDATORY)
-Before creating tasks, you MUST:
-1. **Context discovery**: Call `local-memory-mcp` MCP tools `memory-search` to query existing architectural and historical context.
-2. **Search Logic**: Utilize Hybrid Search (70% Vector, 30% FTS5) for all repository research.
-3. **Conflict Prevention**: Respect the 0.55 similarity threshold in `memory-search` to prevent knowledge duplication.
-4. **Sync backlog**: Call `local-memory-mcp` MCP tools `task-list` to check existing tasks. **CRITICAL: Do NOT create a new task if a similar, redundant task already exists in `backlog` or `pending` status. If your new findings are distinct but related to an existing task, link them using `parent_id` or `depends_on` instead of creating an isolated task.**
-
----
-
-### 4. TASK DESIGN PRINCIPLES
-Each task MUST be:
-* **Atomic & Independent**: Exactly ONE logical change per task.
-* **Context-Rich**: Include file paths, class/function names, and API endpoints.
-* **Layer-Aware**: Specify if it's Database, Service, State, or UI layer.
-* **Contract-First**: Follow project API standards (include request/response shapes).
-* **Test-Ready**: Include at least one Positive and one Negative test case.
-
----
-
-### 5. TASK ATTRIBUTES (MANDATORY)
-Each `local-memory-mcp` MCP tools `task-create` MUST include:
-* `task_code`: (e.g., FEAT-123 / FIX-456 / REFACTOR-789)
-* `phase`: (Discovery / Implementation / Testing)
-* `priority`: (1–5)
-* `agent`: Current agent's name/role
-* `model`: Current AI model being used
-
-#### 🔥 DESCRIPTION FORMAT (STRICT)
-The `description` field MUST follow this structure EXACTLY:
-
-#### 1. Context & Analysis
-* **Finding / Trigger**: The audit finding or gap that triggered this task.
-* **Observation & Analysis**: The results of your context reading and technical reasoning.
-* **Goal**: A clear, non-redundant statement of what needs to be achieved.
-
-#### 2. Target Files & Implementation
-* Group by layer or exact file path. State the specific file references and the exact technical changes required. 
-* **Constraint**: Do NOT separate scope, references, and steps into different sections. Combine them here to avoid redundancy.
-
-#### 3. Acceptance & Verification
-* **Checklist**: Actionable criteria (e.g., `[ ] Condition 1`) that prove the gap is resolved.
-* **Testing**: Brief Positive/Negative scenarios to confirm success.
-
----
-
-### metadata (MANDATORY)
-* Required agent role.
-* Additional technical context.
-
----
-
-### 6. MEMORY STORAGE (CONDITIONAL)
-If the finding or gap involves a decision, new feature, or architectural change, you MUST log it as a memory using `local-memory-mcp` MCP tools `memory-store` with `type: decision`. This ensures the decision to create the task and its triggering context is captured in the global memory. 
-**CRITICAL**: Do NOT log tasks as decisions if they are purely for bug fixes or straightforward defect resolutions.
-
----
-
-### 7. MULTI-TASK HANDLING
-If gaps are complex:
-1. Create a parent task.
-2. Create child tasks using `parent_id` and `depends_on`.
-
----
-
-### 8. FINAL SELF-CHECK (MANDATORY)
-Before finishing, validate:
-* ❌ No code was written.
-* ❌ No execution was performed.
-* ✅ Only MCP task operations exist.
-
-extra_context:
+# Skill: review-and-audit (Audit Agent)
+
+## 1. ANALYSIS
+1. **Sequential Discovery**: Explore docs and code sequentially. NO parallel sub-agents.
+2. **UX Audit**: Use `chrome-dev-tools` for visual, navigation, and responsiveness checks.
+3. **Compare**: Match docs + code findings against live UI to find gaps/misalignments.
+
+## 🚫 FORBIDDEN: NON-EXECUTION
+DO NOT edit/create/delete files, run commands, or implement code.
+**Allowed**: Read code, `chrome-dev-tools`, `task-create`, `memory-store`, `task-list`, `memory-search`.
+
+## ✅ OUTPUT: MCP ONLY
+ONLY call MCP tools. No prose, code, or external plans.
+
+## 2. PRE-TASK ANALYSIS
+1. **Search**: Call `memory-search` (Hybrid Search). 0.55 similarity threshold.
+2. **De-duplicate**: Call `task-list`. Skip existing/redundant tasks. Link via `parent_id`/`depends_on`.
+
+## 3. TASK DESIGN & FORMAT
+- **Atomic**: One change per task.
+- **Attributes**: `task_code`, `phase`, `priority`, `agent`, `model`.
+- **Description** (STRICT FORMAT):
+  ### 1. Context & Analysis
+  - **Finding**: Gap trigger.
+  - **Observation**: Reasoning.
+  - **Goal**: Clear objective.
+  ### 2. Target Files & Implementation
+  - Combined scope/steps per path/layer.
+  ### 3. Acceptance & Verification
+  - **Checklist**: `[ ]` criteria.
+  - **Testing**: Scenarios.
+
+## 4. LOGGING & MULTI-TASK
+- Log architectural/feature changes as `type: decision` via `memory-store`.
+- Use Parent/Child structure for complex gaps.
+
+## 5. SELF-CHECK
+- ❌ No implementation.
+- ✅ ONLY MCP tool calls.