@vheins/local-memory-mcp 0.8.30 → 0.8.33

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

@@ -1,60 +1,47 @@
 ---
 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.
+
+## Task Cache (MANDATORY)
+- `task-detail` MUST be called at most ONCE per task
+- result MUST be reused across all steps
+- do NOT re-fetch or re-inject full detail
+
+## 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.30",
+	"version": "0.8.33",
 	"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",