@vheins/local-memory-mcp 0.8.29 → 0.8.32

package/dist/prompts/review-and-post-issue.md

@@ -1,103 +1,50 @@
 ---
 name: review-and-post-issue
-description: Audit documentation against implementation and generate GitHub issues for gaps.
+description: Audit documentation against implementation; generate GitHub issues for gaps.
 arguments:
   - name: owner
-    description: GitHub repository owner (e.g., 'facebook')
+    description: GitHub repo owner.
     required: true
   - name: repo
-    description: GitHub repository name (e.g., 'react')
+    description: GitHub repo name.
     required: true
   - name: target
-    description: Target module, feature, or component to audit
+    description: Module, feature, or component to audit.
     required: false
 agent: Quality Auditor
 ---
-# Skill: review-and-post-issue
-
-## 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 **GitHub Issues** 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. **Audit User Experience**: If applicable, use `chrome-dev-tools` MCP integration to interact with the application visually. You must audit the actual 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. Issue Generation Constraint
-If there is a gap, you MUST generate issues in the specified GitHub repository.
-When generating issues, you MUST strictly follow high-quality engineering standards:
-
-#### 🚫 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
-
-**Allowed Actions:**
-* Read code and analyze context
-* Use `chrome-dev-tools` MCP to inspect browser UX
-* Search memory via `local-memory-mcp` MCP tools `memory-search`
-* Search GitHub issues via **Github MCP Server Tools (search_issues)**
-* Create GitHub issues via **Github MCP Server Tools (issue_write)** (method: 'create')
-
----
-
-### ✅ ALLOWED OUTPUT (STRICT)
-If gaps are found, your output MUST ONLY consist of calls to:
-* **Github MCP Server Tools (search_issues)**
-* **Github MCP Server Tools (issue_write)**
-* `local-memory-mcp` MCP tools `memory-search`
-
-**❌ DO NOT:**
-* Output explanations or narrative text
-* Output code or plans outside GitHub
-* Suggest fixes directly
-
----
-
-### 3. PRE-ANALYSIS FOR ISSUE GENERATION (MANDATORY)
-Before creating issues, 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 GitHub Backlog**: Call **Github MCP Server Tools (search_issues)** with relevant keywords to check for existing issues. **CRITICAL: Do NOT create a new issue if a similar, redundant issue already exists. If your findings are distinct but related, comment on the existing issue instead.**
-
----
-
-### 4. ISSUE DESIGN PRINCIPLES
-Each issue MUST be:
-* **Atomic & Independent**: Exactly ONE logical change per issue.
-* **Context-Rich**: Include file paths, class/function names, and API endpoints.
-* **Layer-Aware**: Specify if it's Database, Service, State, or UI layer.
-* **Test-Ready**: Include at least one Positive and one Negative test case.
-
----
-
-### 5. DESCRIPTION FORMAT (STRICT)
-The `body` of each GitHub issue MUST follow this structure EXACTLY:
-
-#### 1. Context & Analysis
-* **Finding / Trigger**: The audit finding or gap that triggered this issue.
-* **Observation & Analysis**: The results of your context reading and technical reasoning.
-* **Goal**: A clear 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.
-
-#### 3. Acceptance & Verification
-* **Checklist**: Actionable criteria (e.g., `[ ] Condition 1`) that prove the gap is resolved.
-* **Testing**: Brief Positive/Negative scenarios to confirm success.
-
----
-
-### 6. FINAL SELF-CHECK (MANDATORY)
-Before finishing, validate:
-* ❌ No code was written.
-* ❌ No execution was performed.
-* ✅ Only GitHub issue operations and memory searches exist.
+# Skill: review-and-post-issue (Audit Agent)
+
+## 1. ANALYSIS
+1. **Sequential Discovery**: Explore docs and code sequentially. NO parallel sub-agents.
+2. **UX Audit**: If applicable, use `chrome-dev-tools` for visual, navigation, and responsiveness checks.
+3. **Compare**: Match 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`, `memory-search`, GitHub `search_issues`, `issue_write`.
+
+## ✅ OUTPUT: GITHUB ONLY
+ONLY call: `search_issues`, `issue_write` (method: 'create'), `memory-search`.
+No prose. No external plans.
+
+## 2. PRE-ISSUE ANALYSIS
+1. **Search**: Call `memory-search` (Hybrid Search). 0.55 similarity threshold.
+2. **De-duplicate**: Call `search_issues`. Skip existing/redundant issues. Comment on related issues if distinct.
+
+## 3. ISSUE DESIGN & FORMAT
+- **Atomic**: One change per issue.
+- **Body** (STRICT FORMAT):
+  ### 1. Context & Analysis
+  - **Finding**: Gap trigger.
+  - **Observation**: Reasoning.
+  - **Goal**: Clear objective.
+  ### 2. Target Files & Implementation
+  - Path/layer specific changes.
+  ### 3. Acceptance & Verification
+  - **Checklist**: `[ ]` criteria.
+  - **Testing**: Scenarios.
+
+## 4. SELF-CHECK
+- ❌ No implementation.
+- ✅ ONLY GitHub/Memory tool calls.

package/dist/prompts/root-cause-analysis.md

@@ -1,27 +1,27 @@
 ---
 name: root-cause-analysis
-description: Apply structured 5-Why analysis to trace bugs to their origin
+description: 5-Why analysis to trace bug origins.
 arguments:
   - name: tech_stack
-    description: Target technology stack
+    description: Target tech stack.
     required: true
   - name: bug_description
-    description: Observable symptom or bug behavior
+    description: Bug behavior.
     required: true
   - name: symptoms
-    description: Additional errors, logs, metrics
+    description: Logs, errors, metrics.
     required: false
 agent: Diagnostic Lead
 ---
-You are a senior software engineer conducting a root cause analysis for a bug in the current repository.
+Conduct root cause analysis for repository bug.
 
-Tech stack: {{tech_stack}}
-Bug description: {{bug_description}}
+Stack: {{tech_stack}}
+Bug: {{bug_description}}
 Symptoms: {{symptoms}}
 
-Apply a full **5-Why analysis**:
-1. **Symptom Statement**: Technically restate the problem.
-2. **5-Why Causal Chain**: Trace from symptom to the core process/design/environmental failure.
-3. **Root Cause Statement**: "The root cause is [X] because [Y], which allowed [Z] to occur."
-4. **Fix Recommendation**: Address the root cause, not just the symptom.
-5. **Recurrence Prevention**: Suggest a monitoring or testing measure.
+Output:
+1. **Symptom**: Technical problem restatement.
+2. **5-Whys**: Causal chain from symptom to core failure.
+3. **Root Cause**: "The root cause is [X] because [Y], allowing [Z]."
+4. **Recommendation**: Fix addressing root cause.
+5. **Prevention**: Monitoring/testing measure.

package/dist/prompts/security-triage.md

@@ -1,27 +1,27 @@
 ---
 name: security-triage
-description: Assess security vulnerability reports for exploitability and prioritize remediation
+description: Assess vulnerability exploitability and prioritize fix.
 arguments:
   - name: tech_stack
-    description: Application stack
+    description: App stack.
     required: true
   - name: vulnerability_report
-    description: Report details (CVE, SAST, etc.)
+    description: Report details (CVE, SAST).
     required: true
   - name: codebase_context
-    description: Component usage context
+    description: Usage context.
     required: false
 agent: Security Engineer
 ---
-Act as a senior application security engineer triaging a vulnerability for the current repository.
+Triage vulnerability for repository.
 
 Stack: {{tech_stack}}
 Report: {{vulnerability_report}}
-Codebase context: {{codebase_context}}
+Context: {{codebase_context}}
 
-Please provide:
-1. **Vulnerability Classification**: Type, CVE, CVSS, and attack vector.
-2. **Exploitability Assessment**: Contextual reachability and realistic scenarios.
-3. **Impact Assessment**: Impact on Confidentiality, Integrity, and Availability.
-4. **Remediation Priority & Fix**: Concrete priority (P0-P3) and fix steps.
-5. **Verification**: How to test and verify the fix.
+Output:
+1. **Classification**: Type, CVE, CVSS, vector.
+2. **Exploitability**: Reachability & scenarios.
+3. **Impact**: CIA impact.
+4. **Remediation**: Priority (P0-P3) & fix steps.
+5. **Verification**: Testing method.

package/dist/prompts/senior-code-review.md

@@ -1,33 +1,32 @@
 ---
 name: senior-code-review
-description: Performs a comprehensive production-readiness evaluation for the current repository context
+description: Comprehensive production-readiness evaluation.
 arguments:
   - name: tech_stack
-    description: Target tech stack (e.g., 'Node.js + Express')
+    description: Tech stack.
     required: true
   - name: context
-    description: Production context (traffic, data sensitivity, SLA, conventions)
+    description: Production context (SLA, data, conventions).
     required: false
 agent: Principal Reviewer
 ---
-Act as a principal software engineer performing a production-readiness review for the current repository.
+Perform production-readiness review for repository.
 
 Stack: {{tech_stack}}
 Context: {{context}}
 
-Please review the current code/changes against these 6 dimensions:
-1. **Error Handling Completeness**
-2. **Security** (Injection, Input validation, PII/Secrets)
-3. **Performance** (Time/Memory complexity, DB queries)
-4. **Observability** (Logging, Metrics, Tracing)
-5. **Test Coverage**
-6. **Documentation**
+Audit Dimensions:
+1. **Errors**: Completeness & patterns.
+2. **Security**: Validation, injection, secrets.
+3. **Performance**: Complexity, DB efficiency.
+4. **Observability**: Logs, metrics, traces.
+5. **Testing**: Coverage & quality.
+6. **Docs**: Clarity & accuracy.
 
-For each finding, provide:
-- **Severity**: P0-P3
-- **Dimension**: One of the above
-- **Location**: Specific function/line
-- **Problem**: What is wrong and why it matters
-- **Fix**: Actionable recommendation
+Output per Finding:
+- **Severity**: P0-P3.
+- **Problem**: What & why.
+- **Location**: Path/function.
+- **Fix**: Actionable step.
 
-Produce a **Production Readiness Verdict**: READY | READY WITH MINOR FIXES | NOT READY
+Verdict: READY | READY WITH MINOR FIXES | NOT READY

package/dist/prompts/session-planner.md

@@ -1,18 +1,18 @@
 ---
 name: session-planner
-description: Break down a complex objective into atomic tasks for the current repository
+description: Break objective into atomic tasks.
 arguments:
   - name: objective
-    description: The high-level goal for this session
+    description: High-level session goal.
     required: true
 agent: Strategy Lead
 ---
-Our objective for today in the current repository is: '{{objective}}'.
+Plan execution for: '{{objective}}'.
 
-Please act as a project manager and plan the execution:
-1. **Analyze**: Break this objective down into 3-7 small, atomic, and verifiable tasks.
-2. **Execute**: Use 'task-manage' with action='create' to add these to the local tracker for the current repo.
-3. **Hierarchy**: Use 'parent_id' or 'depends_on' if there is a clear order of operations.
-4. **Phases**: Group tasks into phases like 'research', 'implementation', and 'validation'.
+Steps:
+1. **Analyze**: Break into 3-7 atomic, verifiable tasks.
+2. **Phase**: Group into 'research', 'implementation', 'validation'.
+3. **Hierarchy**: Use `parent_id` / `depends_on` for sequencing.
+4. **Create**: Use `task-create` in current repo.
 
-Display the created plan to the user when done.
+Display final plan to user.

package/dist/prompts/task-management-guidelines.md

@@ -1,28 +1,23 @@
 ---
 name: task-management-guidelines
-description: Best practices for task tracking and progress management
+description: Task tracking & progress management standards.
 arguments: []
 agent: Project Manager
 ---
-Guidelines for Task Management:
+# Task Management Standards
 
-1. task-list (PRIMARY NAVIGATION & SEARCH):
-   - MANDATORY: Always call `local-memory-mcp` MCP tools `task-list` (with no status specified to get active tasks) at the very start of a new session.
-   - Returns a compact table: columns = [id, task_code, title, status, priority, comments_count]. Rows are pointers — NOT full tasks.
-   - Default behavior: returns `in_progress` and `pending` tasks if `status` is omitted.
-   - Filter by status via the `status` param (comma-separated, e.g., `"in_progress,pending"`).
-   - Search by keyword matching task_code, title, or description via the `query` param.
-   - After selecting a task from the table, fetch its full context via `task-detail` tool.
-   - Coordinate: If a task is already 'in_progress', do not attempt to work on it unless specifically asked to collaborate.
-   - DO NOT work on multiple tasks simultaneously.
+## 1. NAVIGATION (`task-list`)
+-   **Sync**: Call `task-list` at every session start (default: `in_progress,pending`).
+-   **Format**: Compact table (IDs only). Use `query` for keyword search.
+-   **Retrieve**: Fetch full context via `task-detail` AFTER selecting a task.
+-   **Coordination**: NEVER work on `in_progress` tasks assigned to others. Focus on ONE task at a time.
 
-3. Detail Tools:
-   - Use `local-memory-mcp` MCP tools `task-detail` to fetch full task details (including comments and history) by ID or task_code.
-   - Use `local-memory-mcp` MCP tools `memory-detail` to fetch full memory content by ID.
+## 2. DETAIL TOOLS
+-   **Tasks**: Call `task-detail` for history/comments (ID or `task_code`).
+-   **Memory**: Call `memory-detail` for full entry content.
 
-4. Workflow Integration:
-   - Plan first: Create tasks for the entire lifecycle (Research → Strategy → Execution → Validation).
-   - Atomic Updates: Update the task status to 'in_progress' EXACTLY ONCE when you begin working on a task.
-   - Workflow Enforcement (MANDATORY): You cannot move a task from 'pending' or 'backlog' directly to 'completed'. You MUST transition to 'in_progress' first for status transition safety.
-   - Finalize: Only mark a task as 'completed' after successful validation (tests passed).
-   - Automatic Archiving: Marking a task as 'completed' automatically triggers `archiveTaskToMemory`, creating a 'task_archive' memory entry with the full history and token usage report.
+## 3. WORKFLOW
+-   **Planning**: Create tasks for full lifecycle (Research → Strategy → Execution → Validation).
+-   **Transition Safety**: MUST move from `backlog/pending` → `in_progress` → `completed`. Skipping `in_progress` is forbidden.
+-   **Validation**: Only `complete` after passing tests.
+-   **Archiving**: Completion triggers auto-archive to `task_archive` memory with token reporting.

package/dist/prompts/task-memory-executor.md

@@ -1,60 +1,42 @@
 ---
 name: task-memory-executor
-description: Execute all pending tasks for the current repository, updating status and storing handoffs in the task backlog.
+description: Sequentially execute pending tasks for current repository.
 arguments: []
 agent: Task Executor
 ---
 # Skill: task-memory-executor
 
-## Purpose
-
-You are tasked with executing all available tasks for the current repository.
-
-## Instructions
-
----
-description: Execute all pending tasks for the current repository
----
-
-Please follow this strict execution flow:
-
-1. **Identify Repository**: Determine the current repository name (e.g., from git config or workspace context).
-2. **Fetch Active Tasks**: Call `local-memory-mcp` MCP tools `task-list` for the identified repository (defaults to active tasks).
-   - This returns a compact table: `columns = [id, task_code, title, status, priority, comments_count]`, `rows` = task pointers.
-   - DO NOT call task-list in a loop. Call it ONCE.
-3. **Filter Stale**: From the in_progress rows, identify tasks that are **stale** (stale = no update for > 30 minutes, often because an agent stopped or crashed). Fetch their full data via `task-detail` tool to inspect timestamps.
-4. **Task Execution Loop**: You MUST process tasks EXACTLY ONE AT A TIME (STRICT). You are STRICTLY FORBIDDEN from spinning up parallel sub-agents or using parallel execution. For each task you select:
-    - **Hydrate**: Fetch full task context via `task-detail` tool before starting work.
-    - **Start**: Call `local-memory-mcp` MCP tools `task-update` to set status='in_progress' for this task ONLY. Provide current agent/role information in the metadata.
-    - **Transition Safety (MANDATORY)**: You are FORBIDDEN from transitioning a task straight to `completed`. You MUST set it to `in_progress` first.
-    - **Execute**: Perform the work described in the task title and description.
-    - **Context Gathering**: Utilize Hybrid Search (70% Vector, 30% FTS5) for all repository research.
-    - **Inspect Codebase Logic & Documentation First (MANDATORY)**: Before marking anything done, inspect the relevant code paths, call sites, configs, tests, and affected modules in the repository. Also read the relevant documentation, as it might need to be updated or fixed. Do not infer correctness from file presence alone.
-    - **Validate Behavior (MANDATORY)**: Ensure the implementation logic satisfies the task intent and follows project standards. Validation must focus on behavior, control flow, data flow, and integration points, not just whether a file/class/function exists.
-    - **Complete Only With Evidence**: Call `local-memory-mcp` MCP tools `task-update` to set status='completed' only after recording concrete evidence in the 'comment' field. The comment must include: files inspected, logic verified, checks/tests run (or why they could not run), and the exact reason the task is considered complete.
-    - **Compact Context**: Summarize key learnings, decisions, and patterns discovered during task execution. Store critical insights as memory entries (type: 'code_fact' or 'pattern') using `local-memory-mcp` MCP tools `memory-store`.
-    - **Retrospective**: Invoke the `learning-retrospective` skill. If the skill is unavailable, use the `learning-retrospective` prompt from `local-memory-mcp` to extract and store durable knowledge (mistakes, decisions, patterns) from this task.
-    - **Commit**: Perform an atomic git commit and push for the changes made in the task.
-    - **Handoff**: Use `local-memory-mcp` MCP tools `task-update` to document **detailed fix steps**, milestones, project-specific knowledge gained during execution, and validation evidence. If complex, decompose into smaller tasks using `local-memory-mcp` MCP tools `task-create`.
-    - **Next**: Call `task-list` once more (optionally with `status='in_progress,pending'`) to get the next actionable task and repeat this loop.
-5. **Backlog Migration**: Once all 'pending' and 'in_progress' tasks are completed or blocked, call `local-memory-mcp` MCP tools `task-list` with status='backlog'. If any exist, select up to 20 tasks (prioritizing by priority field) and update their status to 'pending' using `local-memory-mcp` MCP tools `task-update` to ensure the next agent has work ready.
-6. **Report**: After processing all tasks, provide a summary of your progress.
-
-## Mandatory Validation Rules
-
-Before a task can be marked `completed`, the agent **must** satisfy all applicable rules below:
-
-1. **Read the implementation, not just the filesystem**
-   - Inspect the actual source files related to the task.
-   - Trace the relevant logic path end-to-end using code search and file reads.
-   - Verify how the changed code is invoked, not just that it exists.
-
-2. **Confirm behavior against task intent**
-   - Compare the implementation against the task title, description, acceptance criteria, or bug report.
-   - Check that the business logic is actually implemented and wired correctly.
-   - If the task affects existing behavior, inspect adjacent modules and integration points for regressions.
-
-3. **Use concrete verification**
-   - Run targeted tests, linters, type checks, or validation scripts if available.
-   - If automated tests cannot be run, perform a manual logic audit of all affected paths.
-   - Document the specific verification method used in the task completion comment.
+## 1. SYNC & FILTER
+1. **Identify**: Get repo name (git/context).
+2. **List**: Call `task-list` ONCE for active tasks.
+3. **Audit**: Identify stale `in_progress` tasks (>30m no update). Hydrate via `task-detail` to check timestamps.
+
+## 2. EXECUTION LOOP
+1. **Parallelism & Sub-Agents**: 
+   - **MANDATORY**: Tasks MUST be delegated to sub-agents if the current agent has sub-agent capabilities.
+   - **Concurrency**: Use up to 4 parallel sub-agents. Each sub-agent executes EXACTLY ONE task at a time.
+   - **Fallback**: If the current agent CANNOT spawn sub-agents, it MUST execute tasks sequentially (exactly ONE concurrent task) until the queue is clear.
+2. **Hydrate**: Fetch full context via `task-detail` for the assigned task.
+3. **Start**: `task-update` status to `in_progress` (MUST transition: `pending` → `in_progress`). Add agent/role metadata.
+4. **Research**: Call `memory-search` (Hybrid Search).
+5. **Execute**: 
+   - **Trace**: Inspect logic, call sites, and docs. DO NOT infer from file presence.
+   - **Logic**: Implement per description/intent.
+6. **Validate**: 
+   - Trace path end-to-end.
+   - Run tests/linters/type-checks.
+   - Logic audit for all affected paths.
+7. **Finalize**: 
+   - **Evidence**: `task-update` status to `completed` with detailed 'comment' (inspected files, verified logic, test results).
+   - **Memory**: Store insights as `code_fact`/`pattern` via `memory-store`.
+   - **Retrospective**: Invoke `learning-retrospective`.
+   - **Commit**: Atomic git commit/push.
+8. **Repeat**: Claim next task from `task-list`.
+
+## 3. BACKLOG MAINTENANCE
+If active queue is empty:
+1. Call `task-list` (status: `backlog`).
+2. Move up to 20 high-priority tasks to `pending` via `task-update`.
+
+## 4. REPORT
+Provide progress summary.

package/dist/prompts/tech-affinity-scout.md

@@ -1,15 +1,15 @@
 ---
 name: tech-affinity-scout
-description: Find relevant best practices from other projects with similar tech for the current repository
+description: Scout best practices from similar tech projects.
 arguments:
   - name: tags
-    description: Comma-separated tech tags (e.g., 'react, tailwind')
+    description: CSV tech tags (e.g., 'react, tailwind').
     required: true
 agent: Tech Scout
 ---
-I am working on the current repository using [{{tags}}].
+Scout for relevant knowledge using tags: [{{tags}}].
 
-Please scout for relevant knowledge from other projects:
-1. **Search**: Use `local-memory-mcp` MCP tools `memory-search` with current_tags=[{{tags}}] and include_archived=false.
-2. **Filter**: Look for 'patterns' or 'decisions' from other repositories that might apply here.
-3. **Translate**: Explain how these external best practices can be adapted to our current project context.
+Steps:
+1. **Search**: Call `memory-search` with `current_tags=[{{tags}}]`.
+2. **Filter**: Identify applicable 'patterns' or 'decisions' from other repos.
+3. **Adapt**: Explain adaptation of these practices to current project.

package/dist/prompts/technical-planning.md

@@ -1,20 +1,20 @@
 ---
 name: technical-planning
-description: Define the technical blueprint for a new feature or product
+description: Technical blueprint for new feature/product.
 arguments:
   - name: objective
-    description: The high-level goal for the plan
+    description: High-level goal.
     required: true
 agent: Technical Architect
 ---
-You are tasked with creating a technical blueprint for the following objective in the current repository: '{{objective}}'.
+Create technical blueprint for: '{{objective}}'.
 
-Please cover:
-1. **Tech Stack**: Confirm or select the stack.
-2. **Architecture**: Component layout and data flow.
-3. **Domain Model**: Entities, value objects, and events.
-4. **Database Schema**: Normalized tables and relationships.
-5. **API Contracts**: Endpoint definitions (request/response/errors).
-6. **Roadmap & Sprints**: Phased delivery plan.
+Cover:
+1. **Tech Stack**: Selected/confirmed technologies.
+2. **Architecture**: Components & data flow.
+3. **Domain Model**: Entities, value objects, events.
+4. **Database**: Normalized schema & relationships.
+5. **API Contracts**: Requests, responses, errors.
+6. **Execution**: Roadmap & phased delivery.
 
-Present a cohesive technical design and obtain feedback before proceeding to implementation.
+Present design for feedback before implementation.

package/dist/prompts/tool-usage-guidelines.md

@@ -1,22 +1,22 @@
 ---
 name: tool-usage-guidelines
-description: Prevent tool abuse and ensure data integrity
+description: Tool usage standards & data integrity.
 arguments: []
 agent: System Architect
 ---
-Guidelines for specific tools:
+# Tool Usage Standards
 
-1. memory-store: 
-   - Always include 'tags' for tech-stack identification.
-   - Use 'is_global: true' only for universal preferences (e.g., "Always use tabs").
-   - Use 'supersedes' when overriding a previous decision.
+1. **`memory-store`**: 
+   - Tag by tech-stack. 
+   - `is_global` ONLY for universal rules. 
+   - Use `supersedes` for overrides.
 
-2. memory-search:
-   - Always provide 'current_file_path' for folder-based ranking boost.
-   - Provide 'current_tags' to pull relevant best-practices from other projects.
+2. **`memory-search`**: 
+   - Provide `current_file_path` for scoped ranking. 
+   - Use `current_tags` for affinity-based discovery.
 
-3. memory-acknowledge:
-   - Mandatory feedback loop. Report 'used' if the memory helped, or 'contradictory' if you found an issue.
+3. **`memory-acknowledge`**: 
+   - **Mandatory**. Report `used` or `contradictory`.
 
-4. memory-update:
-   - Use this to keep facts current. Do not create duplicates.
+4. **`memory-update`**: 
+   - Maintain accuracy. Avoid duplicates.

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "@vheins/local-memory-mcp",
-	"version": "0.8.29",
+	"version": "0.8.32",
 	"description": "MCP Local Memory Service for coding copilot agents",
 	"mcpName": "io.github.vheins/local-memory-mcp",
 	"type": "module",
@@ -70,7 +70,7 @@
 		"eslint": "^10.2.0",
 		"eslint-config-prettier": "^10.1.8",
 		"eslint-plugin-prettier": "^5.5.5",
-		"eslint-plugin-svelte": "^2.46.1",
+		"eslint-plugin-svelte": "^3.17.0",
 		"fast-check": "^4.6.0",
 		"globals": "^17.5.0",
 		"prettier": "^3.8.2",