@vheins/local-memory-mcp 0.14.3 → 0.14.4

package/dist/{chunk-D7KJMBPW.js → chunk-U67YH7MG.js}

@@ -81,8 +81,8 @@ function loadServerInstructions() {
 // src/mcp/capabilities.ts
 var __dirname2 = path2.dirname(fileURLToPath2(import.meta.url));
 var pkgVersion = "0.1.0";
-if ("0.14.3") {
-  pkgVersion = "0.14.3";
+if ("0.14.4") {
+  pkgVersion = "0.14.4";
 } else {
   let searchDir = __dirname2;
   for (let i = 0; i < 5; i++) {

package/dist/dashboard/server.js

@@ -16,7 +16,7 @@ import {
   handleTaskClaim,
   listResources,
   logger
-} from "../chunk-D7KJMBPW.js";
+} from "../chunk-U67YH7MG.js";
 
 // src/dashboard/server.ts
 import express from "express";

package/dist/mcp/server.js

@@ -60,7 +60,7 @@ import {
   toContextSlug,
   updateSessionFromInitialize,
   updateSessionRoots
-} from "../chunk-D7KJMBPW.js";
+} from "../chunk-U67YH7MG.js";
 
 // src/mcp/server.ts
 import readline from "readline";

package/dist/prompts/architecture-design.md

@@ -3,25 +3,31 @@ name: architecture-design
 description: Plan system architecture, component layout, and data flow
 arguments:
   - name: tech_stack
-    description: Technology stack. Optional — auto-detected from repo package files, language, and active task tags if omitted.
-    required: false
+    description: Technology stack
+    required: true
   - name: requirements
-    description: Key requirements. Optional — inferred from active task description, pending handoff, or recent conversation if omitted.
-    required: false
+    description: Key requirements
+    required: true
 agent: System Architect
+version: "1.0.0"
+category: planning
+tags: [architecture, system-design, components, data-flow, adr]
 ---
-## 0. CONTEXT RESOLUTION
-- **tech_stack**: If provided, use directly. If omitted — detect from package.json, pyproject.toml, Gemfile, or repo file extensions.
-- **requirements**: If provided, use directly. If omitted — extract from active `in_progress` task description, pending handoff context, or recent conversation.
 
-Design system architecture for the active repository.
+# Skill: Architecture Design
 
-Stack: (resolved above)
-Requirements: (resolved above)
+> Design system architecture for repository.
 
-Output:
-1. **Component Diagram**: Blocks & responsibilities.
-2. **Data Flow**: Information movement.
-3. **ADRs**: Rationale for patterns.
-4. **Scalability/Reliability**: Growth & failure handling.
-5. **Security**: Identity, protection, boundaries.
+## I/O
+`tech_stack` (req), `requirements` (req) → `design/architecture/` (components, data flow, ADRs)
+
+## Rules
+- Component Diagram: Blocks & responsibilities
+- Data Flow: Information movement
+- ADRs: Rationale for patterns
+- Scalability/Reliability: Growth & failure handling
+- Security: Identity, protection, boundaries
+
+## Chain
+← N/A
+→ `architecture-documentation`: `design/architecture/` → as-built architecture doc

package/dist/prompts/create-task.md

@@ -6,6 +6,13 @@ arguments:
     description: Directive to analyze and break into tasks. Optional — derived from active task, pending handoff, or recent conversation if omitted.
     required: false
 agent: Task Planner
+version: "1.0.0"
+license: Proprietary — Personal Use Only
+category: workflows
+type: Orchestrator
+complexity: Advanced
+tags: [workflow, task-creation, planning, mcp]
+author: vheins
 ---
 
 ## 🚫 FORBIDDEN: NON-EXECUTION
@@ -56,6 +63,36 @@ Log architectural/feature changes as `type: decision` via `memory-store`. Store
 - Parent/Child logic for complex directives.
 - Bulk limit: 500 records.
 
+## 5A. BLUEPRINT ORCHESTRATION IMPORT
+When the instruction source is `idea-to-blueprint`:
+- Create one root parent task for the full SDLC blueprint.
+- Create phase parent tasks for P0 through P10 and final no-gap handoff.
+- Create child tasks for every task breakdown row in the `idea-to-blueprint` skill.
+- Recursively decompose every referenced skill until leaf-level tasks are reached.
+- Preserve phase order with `depends_on`: P0 -> P1 -> G1 -> P2 -> G2 -> P3 -> G3 -> P4/P5 -> P6 -> P7 -> P8 -> P9 -> P10 -> GF.
+- For conditional tasks, create them with explicit condition metadata instead of omitting them:
+  - UI design tasks run when the product has UI.
+  - accessibility tests run when UI exists.
+  - performance/load tests run when capacity risk exists.
+  - database migration tests run when schema changes exist.
+  - microservice/monolith tasks run only when architecture context applies.
+- Gate tasks are internal quality checks. They should not ask for manual approval unless the gate is blocked by No-Go, missing mandatory input, or conflicting requirements.
+- All task descriptions must use the strict Context & Analysis, Step & Implementation, Acceptance & Verification format.
+- Call `task-list` before creation and link to existing related tasks instead of creating duplicates.
+- Store a decision memory summarizing the blueprint task graph and major assumptions.
+
+## 5B. SPRINT PLAN IMPORT
+When the instruction source is `.agents/documents/tasks/sprints/`:
+- Treat sprint files and allocation audit as the source of truth.
+- Create one root parent task for the full delivery scope.
+- Create one sprint parent task per sprint and link each to the root via `parent_id`.
+- Create module/feature child tasks under the sprint where the work is scheduled.
+- Create atomic implementation/testing tasks under the matching module/feature parent.
+- Convert sprint dependency columns and implementation order into `depends_on`.
+- Preserve cross-sprint blockers by linking later sprint tasks to earlier sprint MCP task IDs.
+- Call `task-list` before creation and skip duplicates; link to existing related tasks instead.
+- Store a task creation audit in memory with created, linked, skipped duplicate, and blocked counts.
+
 ## 6. SELF-CHECK
 - ❌ No code/execution.
 - ✅ ONLY MCP tool calls.

package/dist/prompts/csl-from-docs.md

@@ -3,15 +3,18 @@ name: csl-from-docs
 description: Create atomic CSL coding standards entries from a local file or directory path.
 arguments:
   - name: path
-    description: Local path (file or directory) containing documentation or standards. Optional — defaults to docs/, README, or prompts definitions directory of the active repo if omitted.
-    required: false
+    description: Local path (file or directory) containing documentation or standards.
+    required: true
 agent: Documentation Processor
+version: "1.0.0"
+category: workflows
+tags: [workflow, csl, coding-standards, documentation, mcp]
 ---
-## 0. CONTEXT RESOLUTION
-- **path**: If provided, use directly. If omitted — default to `docs/`, `README.md`, or `src/mcp/prompts/definitions/` in the active repo root.
-- **current_repo**: Auto-detect from git remote or active workspace context.
 
-Fetch and convert local documentation from the resolved path into atomic CSL (Coding Standards Library) entries.
+Fetch and convert local documentation from the provided path into atomic CSL (Coding Standards Library) entries for the coding_standards entity.
+
+Path: {{path}}
+Current repo: {{current_repo}}
 
 Goal:
 - Analyze the provided path.

package/dist/prompts/csl-scrapper.md

@@ -3,15 +3,18 @@ name: csl-scrapper
 description: Scrape trusted documentation from a URL into atomic CSL coding standards entries.
 arguments:
   - name: source_url
-    description: Canonical URL for the documentation source to scrape. Optional — if omitted, use the most recently referenced URL from conversation context.
-    required: false
+    description: Canonical URL for the documentation source to scrape.
+    required: true
 agent: Documentation Scraper
+version: "1.0.0"
+category: workflows
+tags: [workflow, csl, scraping, coding-standards, mcp]
 ---
-## 0. CONTEXT RESOLUTION
-- **source_url**: Use `{{source_url}}` if provided. If omitted — extract from the most recently mentioned URL in conversation context or active task description.
-- **current_repo**: Auto-detect from git remote or active workspace context.
 
-Fetch and convert trusted documentation from the resolved URL into atomic CSL (Coding Standards Library) entries.
+Fetch and convert trusted documentation from the provided URL into atomic CSL (Coding Standards Library) entries for the coding_standards entity.
+
+Source URL: {{source_url}}
+Current repo: {{current_repo}}
 
 Goal:
 - Use the web_fetch tool (if available) to retrieve the content of the provided Source URL.

package/dist/prompts/documentation-sync.md

@@ -3,6 +3,13 @@ name: documentation-sync
 description: Sync memory decisions with repository markdown files
 arguments: []
 agent: Documentation Specialist
+version: "1.0.0"
+license: Proprietary — Personal Use Only
+category: workflows
+type: Utility
+complexity: Beginner
+tags: [workflow, documentation, memory, sync]
+author: vheins
 ---
 Reconcile local documentation with stored memories.
 

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

@@ -2,32 +2,39 @@
 name: export-task-to-github
 description: Export local tasks to GitHub Issues
 arguments:
+  - name: owner
+    description: GitHub repo owner
+    required: true
+  - name: repo
+    description: GitHub repo name
+    required: true
   - name: task_id
-    description: Local task ID. Optional — if omitted, all tasks in the active repo are exported.
-    required: false
+    description: Local task ID
+    required: true
 agent: Integration Architect
+version: "1.0.0"
+category: workflows
+tags: [workflow, github, task-sync, mcp]
 ---
 
-## 1. IDENTIFY ACTIVE PROJECT
-1.  **Detect**: Get repo name and owner from git remote (e.g. `git remote get-url origin`) or active workspace context. Parse `owner` and `repo` from the remote URL automatically.
-2.  **Verify**: Confirm the detected `owner`/`repo` before proceeding.
+# Skill: export-task-to-github
 
-## 2. RETRIEVE
-1.  **Scope**: If `task_id` provided — fetch that single task via `task-detail`. If omitted — call `task-list` (status: `pending,in_progress,completed`) to get all tasks in the active repo, then process each.
-2.  **Verify**: Ensure title/description exist per task. Use `memory-search` for gaps.
+## 1. RETRIEVE
+1.  **Fetch**: Call `task-detail` for `task_id`.
+2.  **Verify**: Ensure title/description exist. Use `memory-search` for gaps.
 
-## 3. SYNC CHECK
-1.  **Search**: Use `search_issues` for `task_code` scoped to detected `owner`/`repo`.
+## 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.
 
-## 4. CREATE ISSUE
+## 3. CREATE ISSUE
 If new:
--   **Write**: Use `issue_write` (method: 'create') with detected `owner`/`repo`.
+-   **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`.
 
-## 5. LINK
+## 4. LINK
 -   **Update**: Call `task-update`.
 -   **Metadata**: Add GitHub URL.
 -   **Comment**: "Exported to GitHub Issue #X".

package/dist/prompts/fix-suggestion.md

@@ -3,27 +3,29 @@ name: fix-suggestion
 description: Targeted fix with before/after code and test case.
 arguments:
   - name: tech_stack
-    description: Target tech stack. Optional — inferred from repo/context if omitted.
-    required: false
+    description: Target tech stack.
+    required: true
   - name: bug_description
-    description: Bug behavior. Optional — inferred from active conversation or task context if omitted.
-    required: false
+    description: Bug behavior.
+    required: true
   - name: root_cause
-    description: Identified root cause. Optional — inferred from recent error/log context if omitted.
-    required: false
+    description: Identified root cause.
+    required: true
 agent: Debugging Expert
+version: "1.1.0"
+category: debugging
+tags: [fix, patch, bug-fix, code-change, test-case, debugging]
 ---
 
-## 0. CONTEXT RESOLUTION
-Resolve missing arguments from available context before proceeding:
-- **tech_stack**: Detect from repo language, package files, or active task tags. Fallback: ask agent to infer from open files.
-- **bug_description**: Extract from active task description, recent conversation, or error logs. Fallback: describe observable broken behavior.
-- **root_cause**: Extract from recent analysis, error traces, or `memory-search` results. Fallback: state "unknown — investigation required".
+# Skill: Fix Suggestion
 
-Provide precise, minimal fix for confirmed bug.
+> Provide precise, minimal fix for confirmed bug.
 
-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.
+## I/O
+tech_stack (req), bug_description (req), root_cause (req) → diagnosis report + fix suggestion
+
+## Rules
+1. Explanation: Why it happens and 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

@@ -3,6 +3,13 @@ name: import-github-issues
 description: Import GitHub Issues as local tasks.
 arguments: []
 agent: Integration Scout
+version: "1.0.0"
+license: Proprietary — Personal Use Only
+category: workflows
+type: Orchestrator
+complexity: Intermediate
+tags: [workflow, github, issue-import, mcp]
+author: vheins
 ---
 
 ## 1. FETCH

package/dist/prompts/learning-retrospective.md

@@ -3,15 +3,15 @@ name: learning-retrospective
 description: Harvest knowledge from completed work.
 arguments:
   - name: task_id
-    description: ID or code of completed task. Optional — defaults to most recently completed task in the active repo.
+    description: ID of completed task.
     required: false
 agent: Knowledge Harvester
+version: "1.0.0"
+category: workflows
+tags: [workflow, retrospective, memory, knowledge-management]
 ---
-## 0. CONTEXT RESOLUTION
-1. **Repo**: Auto-detect from git remote or active workspace context. All MCP calls MUST be scoped to this repo.
-2. **Task**: If `task_id` provided — use it directly. If omitted — call `task-list` (status: `completed`, limit: 1, ordered by updated_at desc) to get the most recently completed task.
 
-Extract durable knowledge from the resolved task for the active repository.
+Extract durable knowledge from task {{task_id}} for repository.
 
 Identify and `memory-store`:
 1. **Mistakes**: Hard-to-find bugs or environment quirks.

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

@@ -3,6 +3,13 @@ name: memory-agent-core
 description: Behavioral contract for memory-aware agents.
 arguments: []
 agent: Memory Guardian
+version: "1.0.0"
+license: Proprietary — Personal Use Only
+category: workflows
+type: Utility
+complexity: Advanced
+tags: [memory, workflow, guardrails, mcp]
+author: vheins
 ---
 # Memory Guardian Protocol
 

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

@@ -3,14 +3,15 @@ name: memory-guided-review
 description: Review code for compliance with stored decisions.
 arguments:
   - name: file_path
-    description: File to review. Optional — if omitted, review the currently open/active file in the workspace, or all recently modified files.
-    required: false
+    description: File to review.
+    required: true
 agent: Code Auditor
+version: "1.0.0"
+category: coding
+tags: [code-review, memory, compliance, mcp]
 ---
-## 0. CONTEXT RESOLUTION
-- **file_path**: If provided, use it. If omitted — use the currently active/open file from workspace context, or list recently modified files via git and process them.
 
-Audit the resolved file(s) against stored project knowledge.
+Audit {{file_path}} against stored project knowledge.
 
 Steps:
 1. **Search Memory**: Call `memory-search` using `current_file_path='{{file_path}}'`.

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

@@ -3,6 +3,13 @@ name: memory-index-policy
 description: Strict memory storage criteria.
 arguments: []
 agent: Memory Auditor
+version: "1.0.0"
+license: Proprietary — Personal Use Only
+category: workflows
+type: Utility
+complexity: Beginner
+tags: [memory, indexing, policy, mcp]
+author: vheins
 ---
 # Memory Indexing Rules
 

package/dist/prompts/project-briefing.md

@@ -3,6 +3,13 @@ name: project-briefing
 description: Contextual onboarding to current repository.
 arguments: []
 agent: Session Concierge
+version: "1.0.0"
+license: Proprietary — Personal Use Only
+category: workflows
+type: Utility
+complexity: Beginner
+tags: [workflow, briefing, onboarding, memory, backlog]
+author: vheins
 ---
 Initialize session in repository.
 

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

@@ -3,20 +3,24 @@ name: review-and-audit
 description: Audit documentation against implementation; generate local tasks for gaps.
 arguments:
   - name: target
-    description: Module, feature, or component to audit. Optional — if omitted, audits all available documentation against the full implementation.
+    description: Module, feature, or component to audit.
     required: false
 agent: Quality Auditor
+version: "1.0.0"
+license: Proprietary — Personal Use Only
+category: workflows
+type: Orchestrator
+complexity: Advanced
+tags: [workflow, audit, ux, gap-analysis, mcp]
+author: vheins
 ---
-
-## 0. CONTEXT RESOLUTION
-- **Target**: If `target` provided — scope audit to that module/feature/component. If omitted — **fallback**: audit ALL existing documentation (README, docs/, prompts, schemas) against the full codebase implementation. Enumerate each doc file and compare with corresponding source.
-- **Repo**: Auto-detect from git remote or active workspace context.
+# Skill: review-and-audit (Audit Agent)
 
 ## 1. ANALYSIS
-1. **Discovery**: Explore docs and code. Coding sub-agents MAY be used for parallel file reading if the agent supports sub-agents. `chrome-devtools-mcp` MCP tools (direct tool calls) are **ALLOWED**. **FORBIDDEN**: spawning a `browser_subagent` — do NOT invoke the `browser_subagent` tool here. Distinction: MCP tool call = allowed; spawned browser agent process = forbidden.
-2. **UX Audit**: If target involves UI and the audit explicitly requires visual inspection, note it as a separate task — do NOT block the audit on it.
+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. **Reference Audit**: Check current tool/prompt/resource definitions through code or the dashboard Reference flow.
-4. **Compare**: Match docs + code findings to find gaps/misalignments.
+4. **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.
@@ -40,8 +44,8 @@ ONLY call MCP tools. No prose, code, or external plans.
   - **Finding**: Gap trigger.
   - **Observation**: Reasoning.
   - **Goal**: Clear objective.
-  ### 2. Step & Implementation
-  - Detailed execution steps per path/layer.
+  ### 2. Target Files & Implementation
+  - Combined scope/steps per path/layer.
   ### 3. Acceptance & Verification
   - **Checklist**: `[ ]` criteria.
   - **Testing**: Scenarios.

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

@@ -3,25 +3,26 @@ name: review-and-post-issue
 description: Audit documentation against implementation; generate GitHub issues for gaps.
 arguments:
   - name: owner
-    description: GitHub repo owner. Optional — auto-detected from git remote if omitted.
-    required: false
+    description: GitHub repo owner.
+    required: true
   - name: repo
-    description: GitHub repo name. Optional — auto-detected from git remote if omitted.
-    required: false
+    description: GitHub repo name.
+    required: true
   - name: target
-    description: Module, feature, or component to audit. Optional — if omitted, audits all documentation against the full implementation.
+    description: Module, feature, or component to audit.
     required: false
 agent: Quality Auditor
+version: "1.0.0"
+category: workflows
+tags: [workflow, audit, github, issue-triage]
 ---
 
-## 0. CONTEXT RESOLUTION
-1. **Owner/Repo**: Auto-detect from `git remote get-url origin` or active workspace context. Parse `owner` and `repo` from the remote URL. Verify before proceeding.
-2. **Target**: If `target` provided — scope to that module/feature. If omitted — **fallback**: audit ALL existing documentation against the full codebase.
+# Skill: review-and-post-issue (Audit Agent)
 
 ## 1. ANALYSIS
-1. **Discovery**: Explore docs and code. Coding sub-agents MAY be used for parallel reading if the agent supports sub-agents. **FORBIDDEN: browser sub-agents**.
-2. **UX Audit**: If the target involves UI, note it as a separate GitHub issue — do NOT block audit on visual inspection.
-3. **Compare**: Match docs + code findings to identify gaps/misalignments.
+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.
@@ -42,7 +43,7 @@ No prose. No external plans.
   - **Finding**: Gap trigger.
   - **Observation**: Reasoning.
   - **Goal**: Clear objective.
-  ### 2. Step & Implementation
+  ### 2. Target Files & Implementation
   - Path/layer specific changes.
   ### 3. Acceptance & Verification
   - **Checklist**: `[ ]` criteria.

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

@@ -3,22 +3,25 @@ name: root-cause-analysis
 description: 5-Why analysis to trace bug origins.
 arguments:
   - name: tech_stack
-    description: Target tech stack. Optional — auto-detected from repo/context if omitted.
-    required: false
+    description: Target tech stack.
+    required: true
   - name: bug_description
-    description: Bug behavior. Optional — inferred from active task or recent conversation if omitted.
-    required: false
+    description: Bug behavior.
+    required: true
   - name: symptoms
     description: Logs, errors, metrics.
     required: false
 agent: Diagnostic Lead
+version: "1.0.0"
+category: debugging
+tags: [root-cause, 5-why, debugging, diagnosis]
 ---
-## 0. CONTEXT RESOLUTION
-- **tech_stack**: If provided, use directly. If omitted — detect from repo package files or active task tags.
-- **bug_description**: If provided, use directly. If omitted — extract from active task description or recent error/log context.
-- **symptoms**: Optional. Use if provided; otherwise infer from available logs or error traces.
 
-Conduct root cause analysis for the active repository bug.
+Conduct root cause analysis for repository bug.
+
+Stack: {{tech_stack}}
+Bug: {{bug_description}}
+Symptoms: {{symptoms}}
 
 Output:
 1. **Symptom**: Technical problem restatement.

package/dist/prompts/security-triage.md

@@ -3,22 +3,25 @@ name: security-triage
 description: Assess vulnerability exploitability and prioritize fix.
 arguments:
   - name: tech_stack
-    description: App stack. Optional — auto-detected from repo/context if omitted.
-    required: false
+    description: App stack.
+    required: true
   - name: vulnerability_report
-    description: Report details (CVE, SAST). Optional — extracted from active task description or recent conversation if omitted.
-    required: false
+    description: Report details (CVE, SAST).
+    required: true
   - name: codebase_context
     description: Usage context.
     required: false
 agent: Security Engineer
+version: "1.0.0"
+category: debugging
+tags: [security, triage, vulnerability, cvss, appsec]
 ---
-## 0. CONTEXT RESOLUTION
-- **tech_stack**: If provided, use directly. If omitted — detect from repo package files, language, or active task tags.
-- **vulnerability_report**: If provided, use directly. If omitted — extract from active task description, recent conversation, or attached SAST output.
-- **codebase_context**: Optional. Use if provided.
 
-Triage the resolved vulnerability for the active repository.
+Triage vulnerability for repository.
+
+Stack: {{tech_stack}}
+Report: {{vulnerability_report}}
+Context: {{codebase_context}}
 
 Output:
 1. **Classification**: Type, CVE, CVSS, vector.

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

@@ -3,18 +3,21 @@ name: senior-code-review
 description: Comprehensive production-readiness evaluation.
 arguments:
   - name: tech_stack
-    description: Tech stack. Optional — auto-detected from repo package files, language, or active task tags if omitted.
-    required: false
+    description: Tech stack.
+    required: true
   - name: context
     description: Production context (SLA, data, conventions).
     required: false
 agent: Principal Reviewer
+version: "1.1.0"
+category: coding
+tags: [code-review, production-readiness, security, observability, senior-review, architecture]
 ---
-## 0. CONTEXT RESOLUTION
-- **tech_stack**: If provided, use directly. If omitted — detect from repo package files or language.
-- **context**: Optional. Use if provided; otherwise infer from task description or recent conversation.
 
-Perform production-readiness review for the active repository.
+Perform production-readiness review for repository.
+
+Stack: {{tech_stack}}
+Context: {{context}}
 
 Audit Dimensions:
 1. **Errors**: Completeness & patterns.

package/dist/prompts/sentinel-issue-resolver.md

@@ -6,6 +6,13 @@ arguments:
     description: The full URL of the GitHub issue to resolve.
     required: true
 agent: SENTINEL Issue Resolver
+version: "1.0.0"
+license: Proprietary — Personal Use Only
+category: workflows
+type: Orchestrator
+complexity: Advanced
+tags: [workflow, github, issue-resolution, sentinel]
+author: vheins
 ---
 
 # SENTINEL Protocol
@@ -26,12 +33,14 @@ You are **SENTINEL**, an elite issue resolution agent. Your primary objective is
 1. **Identity**: Use the local Git configuration (name/email) for all commits.
 2. **Commit Format**: Every commit MUST follow this specific structure:
    ```
-   type(scope): [task-code] fix #{{issue_number}} - your commit message
-   
-   - [Task Title]
-     [Summary Task]
+   type(scope): your commit message
+
+   - {{task_title}}
+     {{summary_task}}
+
+   {{keyword}} #{{issue_number}}
    ```
-   *Note: Extract the issue number from the provided `issue_url`.*
+   Use `fix` for bug fixes, `closes` for features/chores, `resolve` as general. Extract the issue number from the provided `issue_url`.
 
 3. **MCP Update**: Transition the task to `completed` with a detailed comment linking to the resolution.
 4. **Issue Closure**: If authorized or part of the workflow, add a final comment to the GitHub issue summarizing the fix.

package/dist/prompts/session-planner.md

@@ -3,14 +3,15 @@ name: session-planner
 description: Break objective into atomic tasks.
 arguments:
   - name: objective
-    description: High-level session goal. Optional — inferred from active task, recent conversation, or pending handoff if omitted.
-    required: false
+    description: High-level session goal.
+    required: true
 agent: Strategy Lead
+version: "1.0.0"
+category: workflows
+tags: [workflow, planning, task-breakdown]
 ---
-## 0. CONTEXT RESOLUTION
-- **objective**: If provided, use directly. If omitted — extract from the active `in_progress` task description, the most recent pending handoff, or the last user request in conversation context.
 
-Plan execution for the resolved objective.
+Plan execution for: '{{objective}}'.
 
 Steps:
 1. **Orient**: Call `task-list` to avoid duplicate active/backlog work.
@@ -20,6 +21,6 @@ Steps:
 5. **Phase**: Group into `research`, `implementation`, and `validation`.
 6. **Hierarchy**: Use `parent_id` / `depends_on` for sequencing.
 7. **Priority Scale**: When creating tasks, use the exact MCP scale `1=Low`, `2=Normal`, `3=Medium`, `4=High`, `5=Critical`. Higher number means higher urgency.
-8. **Create**: Use `task-create` in current repo with stable `task_code`, tags, and acceptance criteria following the format: 1. Context & Analysis, 2. Step & Implementation, 3. Acceptance & Verification.
+8. **Create**: Use `task-create` in current repo with stable `task_code`, tags, and acceptance criteria.
 
 Display final plan to user.

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

@@ -3,6 +3,13 @@ name: task-management-guidelines
 description: Task tracking & progress management standards.
 arguments: []
 agent: Project Manager
+version: "1.0.0"
+license: Proprietary — Personal Use Only
+category: workflows
+type: Utility
+complexity: Beginner
+tags: [workflow, tasks, status-management, mcp]
+author: vheins
 ---
 # Task Management Standards
 

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

@@ -3,27 +3,31 @@ name: task-memory-executor
 description: Sequentially execute pending tasks for current repository.
 arguments:
   - name: agent_identity
-    description: Optional runner identity (e.g., Codex-Jarvis, Codex-HulkBuster, Gemini-Ultron). If omitted, identity is inferred from the active CLI/IDE and a short session token is appended.
+    description: Optional runner identity (e.g., Codex-Jarvis, Codex-HulkBuster, Gemini-Ultron). If omitted, infer identity from the active CLI/IDE and append short session token.
     required: false
 agent: Task Executor
+version: "1.5.4"
+license: Proprietary — Personal Use Only
+category: workflows
+type: Orchestrator
+complexity: Advanced
+tags: [workflow, task-execution, memory]
+author: vheins
 ---
+# Skill: task-memory-executor
 
 ## 1. SYNC & FILTER
-1. **Identify**: Determine runner identity and repo context.
-   - Resolver priority: `agent_identity` argument -> auto session identity generated once per run.
+1. **Identify**: Resolve runner identity + repo name.
+   - Resolver priority: `agent_identity` argument -> auto-generated session identity for this run.
+   - Compute this once and reuse it across the full execution loop.
    - Auto identity format: `<runner>-<randomName>`.
    - `<runner>` should come from the active CLI/IDE label (for example `vibe-coding-cli`, `vibe-coding-ide`, `Codex`, `Gemini`) and `<randomName>` is a short stable session token.
-   - Use this identity for all `task-claim`, `task-update`, and handoff writes.
+   - Use this identity in task claim/update and handoff metadata so parallel terminals remain attributable.
 2. **List**: Call `task-list` ONCE for active tasks.
-3. **Dependency-aware selection** (in `task-list` order):
-   - Process tasks in the order returned by `task-list`.
-   - A task is READY only if:
-     - status is `backlog` or `pending`, and
-     - `depends_on` is empty, or the dependency task exists and is `completed`, and
-     - `parent_id` is empty, or the parent task is `completed`.
-   - Keep non-ready tasks out of execution for now.
-   - If a task is blocked by unresolved dependency/parent, do not claim it and continue to the next ready task.
-   - If all active tasks are blocked, report blockers and stop execution loop.
+3. **Dependency-ready filtering**: In the returned `task-list` order, only run `backlog`/`pending` tasks where:
+   - `depends_on` is empty or completed, and
+   - `parent_id` is empty or completed.
+   - If all are blocked, report blockers and pause.
 4. **Handoffs**: Call `handoff-list` with `status=pending` and inspect relevant transfer context before selecting work. Treat a pending handoff as active only when it has unfinished work, a blocker, a next owner, or a linked task. If it is obsolete or only describes completed work, close it with `handoff-update status=expired`.
 5. **Audit**: Identify stale `in_progress` tasks (>30m no update). Hydrate via `task-detail` to check timestamps.
 
@@ -33,14 +37,14 @@ agent: Task Executor
 - do NOT re-fetch or re-inject full detail
 
 ## 2. EXECUTION LOOP
-1. **Parallelism & Sub-Agents**: 
+1. **Parallelism & Sub-Agents**:
    - **MANDATORY**: Tasks MUST be delegated to sub-agents if the current agent has sub-agent capabilities.
-   - **Decomposition**: If a task is too broad, the agent is allowed to decompose it into multiple tasks (via `task-create`) and delegate them to sub-agents. All created tasks MUST follow the format: 1. Context & Analysis, 2. Step & Implementation, 3. Acceptance & Verification.
+   - **Decomposition**: If a task is too broad, the agent is allowed to decompose it into multiple tasks (via `task-create`) and delegate them to sub-agents.
    - **Spawn Limit**: The total number of parallel sub-agents MUST NOT exceed 2. 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. **Readiness re-check**: Re-check blockers from hydrated detail (`depends_on`, `parent_id`) before claim. If still blocked, return to step 2 (execution loop) and pick the next ready task in list order.
-4. **Claim**: Use `task-claim` with `task_code` or `task_id` before implementation, and write the runner identity into claim metadata.
+3. **Readiness re-check**: Re-check `depends_on`/`parent_id` from hydrated detail; if still blocked, skip and pick next ready task.
+4. **Claim**: Use `task-claim` with `task_code` or `task_id` before implementation. Include the runner identity in claim metadata.
 5. **Start**: `task-update` status to `in_progress` (MUST transition: `pending` → `in_progress`). Add agent/role metadata and the same runner identity used by claims.
 6. **Research**: Call `memory-search` (Hybrid Search) and hydrate relevant results with `memory-detail`.
 7. **Standards (MANDATORY PER TASK)**: Call `standard-search` for every task inside the execution loop before any code edit, test edit, refactor, migration, or implementation decision, using the task intent, affected files, inferred language, stack, and repo as filters. This is required even for small tasks, decomposed tasks, and sub-agent assignments. Apply only relevant standards, hydrate details when needed, and if no relevant standards are returned, continue and state that no applicable standards were found.
@@ -57,16 +61,19 @@ agent: Task Executor
    - **Cleanup**: Completing/canceling a task automatically releases active claims and expires linked pending handoffs.
    - **Memory**: Store insights as `code_fact`/`pattern` via `memory-store`.
    - **Standards**: Store durable implementation rules via `standard-store`, not generic memory.
-   - **Handoff**: If work remains or ownership changes, create `handoff-create` with concise summary and structured context containing next steps/blockers/remaining work. Do not create handoffs for completed-work summaries. Include runner identity in handoff metadata/context.
+   - **Handoff**: If work remains or ownership changes, create `handoff-create` with concise summary and structured context containing next steps/blockers/remaining work. Do not create handoffs for completed-work summaries. Include the runner identity in handoff context/metadata.
    - **Retrospective**: Invoke `learning-retrospective`.
-   - **Commit**: Atomic git commit. The commit message MUST follow this format: `type(scope): [task-code] your commit message`, followed by a detailed description:
-     ```
-     - [Task Title]
-       [Summary Task]
-     ```
-     This ensures full traceability between code changes and project context.
-   - **GitHub Issue Traceability**: If task metadata contains a GitHub Issue reference, the commit message MUST also include the issue hashtag in `#123` format.
-   - **Issue Number Extraction**: Read the issue number from task metadata when available. If metadata only contains a GitHub Issue URL, extract the trailing issue number from that URL before committing.
+    - **Commit**: Atomic git commit. The commit message MUST follow this format:
+      ```
+      type(scope): your commit message
+
+      - {{task_title}}
+        {{summary_task}}
+
+      {{keyword}} #{{issue_number}}
+      ```
+      Use `fix` for bug fixes, `closes` for features/chores, `resolve` as general. Multiple issues: e.g., `fix #123, closes #124, resolve #125`. Issues close only when merged into the default branch.
+    - **Issue Number Extraction**: Read the issue number from task metadata when available. If metadata only contains a GitHub Issue URL, extract the trailing issue number from that URL before committing.
 
 10A. **BLOCKER HANDLING (AUTOMATIC TASK CREATION)**:
    - **Trigger**: When task status is updated to `blocked` with a comment explaining the blocker reason.
@@ -82,25 +89,16 @@ agent: Task Executor
      - Task Code: `${parent_task_code}-FIX-${unix_timestamp}`
      - Title: `FIX: [${parent_task_title}] - Resolve: ${blocker_reason_extracted}`
      - Description: Follow standard format (1. Context & Analysis, 2. Step & Implementation, 3. Acceptance & Verification)
-       - Context: Reference parent task code and explain the blocking factor
-       - Steps: Identify root cause and implement fix
-       - Verification: Confirm parent task can proceed
      - Parent ID: Set to current blocked task ID
      - Priority: `4` (HIGH)
      - Phase: `blocker-resolution`
      - Tags: `["blocker-fix", "auto-generated"]`
      - Metadata: Include `triggered_by_task`, `blocker_reason`, `creation_timestamp`, and `agent_identity`
-   - **Update Parent Task**: Add comment linking to the new blocker-fix task: `"Blocker resolution task created: ${new_task_code}"`
-   - **Link Dependencies**: Set parent task's `depends_on` to the new blocker-fix task (parent waits for fix before retry)
+   - **Update Parent Task**: Add comment linking to the new blocker-fix task
+   - **Link Dependencies**: Set parent task's `depends_on` to the new blocker-fix task
    - **Skip Creation** (if external): Log that blocker is external, keep task status as `blocked`, no automatic task created.
 
-11. **Loop**: Follow `~/.agents/AGENTS.md` → **CONTINUOUS EXECUTION MODE**:
-    - `task-list` (pending) → claim next
-    - If empty → promote backlog → loop
-    - If backlog empty → check stale in_progress → loop
-    - If stale empty → check handoff → loop
-    - **Only then → STOP**
-    - **Violation = incomplete execution**
+11. **Repeat**: Claim next task from `task-list`.
 
 ## 3. BACKLOG MAINTENANCE
 If active queue is empty:
@@ -112,90 +110,43 @@ If active queue is empty:
 
 ### Internal Solvable Blocker Patterns (Trigger Auto Task Creation)
 
-**Missing Dependencies/Modules**:
-- `module not found`, `missing dependency`, `import not installed`, `undefined function`, `no such file`
+**Missing Dependencies/Modules**: `module not found`, `missing dependency`, `import not installed`
 - Example: "ImportError: Function 'validateToken' not found"
 
-**Not Implemented**:
-- `function/method not implemented`, `interface not exists`, `component undefined`
+**Not Implemented**: `function not implemented`, `interface not exists`, `component undefined`
 - Example: "Function 'processPayment' not implemented - exists in type definitions but no implementation"
 
-**Configuration/Setup Issues**:
-- `.env missing`, `configuration not set`, `setup invalid`, `environment variable not found`
+**Configuration/Setup Issues**: `.env missing`, `configuration not set`, `setup invalid`
 - Example: "DATABASE_URL environment variable not set"
 
-**Test/Build Failures** (solvable):
-- `test failed`, `assertion failed`, `type error`, `build error`, `compilation failed`
+**Test/Build Failures**: `test failed`, `assertion failed`, `type error`, `build error`
 - Example: "Type error: Property 'user' does not exist on type 'Request'"
 
-**Implementation Gaps**:
-- `endpoint not implemented`, `API route missing`, `middleware not registered`
-- Example: "GET /api/users endpoint returns 404 - not implemented"
-
 ### External Blocker Patterns (Skip Auto Task Creation)
 
-**Awaiting User/External Action**:
-- `awaiting user`, `requires manual`, `user must`, `external dependency`, `manual setup`
-- Example: "Awaiting user approval for database migration", "Requires manual infrastructure setup"
+**Awaiting User/External Action**: `awaiting user`, `requires manual`, `external dependency`
+- Example: "Awaiting user approval for database migration"
 
-**External Service Issues**:
-- `API not responding`, `service unavailable`, `server not ready`
-- Example: "Payment gateway API not responding - external service unavailable"
+**External Service Issues**: `API not responding`, `service unavailable`, `server not ready`
+- Example: "Payment gateway API not responding"
 
-**Manual Prerequisites**:
-- `install locally`, `run script manually`, `requires external tool`
-- Example: "Requires manual Docker setup - not part of this task"
+### Auto Task Creation Example
 
-### Auto Task Creation Example Flow
-
-**Parent Task Blocked:**
+**Parent Task Blocked**:
 ```
-Task Code: FEATURE-42
-Title: Add payment processing middleware
+Task: FEATURE-42 (Add payment middleware)
 Status: blocked
-Comment: "Function 'chargeCard' in services/payment.ts not implemented - exists in interface but implementation missing"
+Comment: "Function 'chargeCard' not implemented"
 ```
 
-**Detection & Classification:**
-```
-Pattern detected: "Function .* not implemented" → INTERNAL SOLVABLE ✅
-Action: Create blocker-fix task
+**Auto-Generated Fix Task**:
 ```
-
-**Auto-Generated Task:**
-```
-Task Code: FEATURE-42-FIX-1714737908
-Title: FIX: [Add payment processing middleware] - Resolve: Function 'chargeCard' not implemented
-Parent ID: FEATURE-42
+Code: FEATURE-42-FIX-1714737908
+Title: FIX: [Add payment middleware] - Resolve: Function 'chargeCard' not implemented
+Parent: FEATURE-42
 Priority: 4 (HIGH)
-Phase: blocker-resolution
 Tags: ["blocker-fix", "auto-generated"]
-
-Description:
-1. Context & Analysis:
-   Parent task FEATURE-42 blocked due to: Function 'chargeCard' in services/payment.ts not implemented
-   The function exists in the interface but has no implementation body
-   Blocking factor: services/payment.ts - chargeCard function stub
-
-2. Step & Implementation:
-   - Review services/payment.ts chargeCard function signature
-   - Implement full payment processing logic (charges, refunds, error handling)
-   - Add proper error handling and validation
-   - Write unit tests for charge scenarios
-
-3. Acceptance & Verification:
-   - chargeCard function fully implemented
-   - Unit tests passing
-   - Function can be called from FEATURE-42 middleware
-   - FEATURE-42 parent task can proceed without blockers
 ```
 
-**Execution Workflow:**
-1. Agent picks blocker-fix task first (independent, no dependencies)
-2. Implements `chargeCard` function
-3. Completes blocker-fix task
-4. Parent task FEATURE-42 becomes ready (fix completed)
-5. Agent proceeds with FEATURE-42 execution
-
 ## 5. REPORT
 Provide progress summary.

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

@@ -3,14 +3,15 @@ name: tech-affinity-scout
 description: Scout best practices from similar tech projects.
 arguments:
   - name: tags
-    description: CSV tech tags (e.g., 'react, tailwind'). Optional — auto-detected from repo package files, file extensions, or active task tags if omitted.
-    required: false
+    description: CSV tech tags (e.g., 'react, tailwind').
+    required: true
 agent: Tech Scout
+version: "1.0.0"
+category: planning
+tags: [planning, patterns, memory, tech-affinity]
 ---
-## 0. CONTEXT RESOLUTION
-- **tags**: If provided, use directly. If omitted — detect from repo package files, file extensions, or active task tags.
 
-Scout for relevant knowledge using detected/provided tags.
+Scout for relevant knowledge using tags: [{{tags}}].
 
 Steps:
 1. **Search**: Call `memory-search` with `current_tags=[{{tags}}]`.

package/dist/prompts/technical-planning.md

@@ -1,23 +1,54 @@
 ---
 name: technical-planning
-description: Technical blueprint for new feature/product.
+description: Technical blueprint for new feature/product, including full-roadmap execution planning.
 arguments:
   - name: objective
-    description: High-level goal. Optional — inferred from active task description, pending handoff, or recent conversation if omitted.
-    required: false
+    description: High-level goal.
+    required: true
 agent: Technical Architect
+version: "1.0.0"
+license: Proprietary — Personal Use Only
+category: workflows
+type: Pipeline
+complexity: Advanced
+tags: [workflow, technical-planning]
+author: vheins
 ---
-## 0. CONTEXT RESOLUTION
-- **objective**: If provided, use directly. If omitted — extract from the active `in_progress` task description, the most recent pending handoff summary, or the last user instruction in conversation context.
 
-Create technical blueprint for the resolved objective.
+# Skill: Technical Planning Pipeline
 
-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.
+## Purpose
+Produces a comprehensive technical blueprint (tech stack, architecture, domain, database, API contracts, execution plan).
 
-Present design for feedback before implementation.
+## Input
+| Variable | Type | Req | Description |
+|----------|------|-----|-------------|
+| `objective` | string | Yes | High-level goal |
+
+## FSM
+Entry: create-task → task-claim   Exit: task-update completed|blocked
+Guard: A(N) requires all prev A✅
+
+A1 | tech-stack-selection           | —    | tech stack decision  | —
+A2 | architecture-design            | A1✅ | architecture plan    | design/architecture/
+G1 | approve stack + arch          | A2✅ | → proceed            | —
+A3 | domain-modeling                | G1✅ | domain model         | design/domain/
+A4 | database-schema-planning       | A3✅ | schema plan          | design/database/
+G2 | approve domain + db           | A4✅ | → proceed            | —
+A5 | api-contract-design            | G2✅ | API contract         | design/api/
+G3 | approve API contracts         | A5✅ | → proceed            | —
+A6 | roadmap-creation + all sprint plans + MCP tasks | G3✅ | roadmap + sprint-1..sprint-N + allocation audit + MCP task tree | tasks/roadmap/ + tasks/sprints/ + local-memory-mcp
+GF | final approve                 | A6✅ | → documentation      | —
+
+## Execution Planning Rule
+A6 MUST cover the full delivery horizon. `sprint-planning` is per sprint, so A6 must derive `total_sprints` from roadmap timeline/capacity and generate one sprint-planning task for every sprint number from 1 through `total_sprints`. After sprint allocation audit passes, A6 must invoke `create-task` to create the Local Memory MCP task tree with parent/child and `depends_on` links. The final approval is blocked if only `sprint-1.md` exists while the roadmap contains later sprint-ready work, or if the MCP task tree was not created from the final sprint plans.
+
+## Optional
+A7  | capacity-planning             | —    | capacity plan        | —
+A8  | event-storming                | —    | domain discovery     | —
+A9  | dependency-mapping            | —    | dependency map       | —
+A10 | microservices-boundary        | —    | service boundaries   | —
+A11 | monolith-decomposition        | —    | migration plan       | —
+A12 | sla-slo-definition            | —    | SLA/SLO doc          | —
+A13 | system-design-review          | —    | review findings      | —
+A14 | tech-affinity-scout           | —    | best practices       | —

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

@@ -3,6 +3,13 @@ name: tool-usage-guidelines
 description: Tool usage standards & data integrity.
 arguments: []
 agent: System Architect
+version: "1.0.0"
+license: Proprietary — Personal Use Only
+category: workflows
+type: Utility
+complexity: Beginner
+tags: [workflow, tooling, memory, policy, mcp]
+author: vheins
 ---
 # Tool Usage Standards
 

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "@vheins/local-memory-mcp",
-	"version": "0.14.3",
+	"version": "0.14.4",
 	"description": "MCP Local Memory Service for coding copilot agents",
 	"mcpName": "io.github.vheins/local-memory-mcp",
 	"type": "module",