ima-claude 2.9.0

package/plugins/ima-claude/skills/mcp-memory/SKILL.md

@@ -0,0 +1,182 @@
+---
+name: "mcp-memory"
+description: "DEPRECATED — Use mcp-vestige instead. Vestige provides semantic search, spaced repetition, auto-dedup, and codebase awareness as a superset of Memory MCP. Triggers on: mcp-memory."
+---
+
+> **DEPRECATED**: This skill is replaced by **mcp-vestige**. Vestige is a superset of Memory MCP with semantic search, FSRS-6 spaced repetition, prediction error gating, and codebase awareness. All proactive memory behaviors now route through Vestige.
+>
+> This file is retained for reference during the transition period.
+
+# Memory MCP - Proactive Knowledge Graph (DEPRECATED)
+
+**You have access to a persistent knowledge graph that you rely on across all sessions.**
+
+Like Serena for code operations, Memory MCP is your system for preserving context. You use it **proactively** without being asked - checking for relevant context, storing decisions as they're made, and capturing learnings.
+
+## Proactive Behavior Rules
+
+**These are MUST behaviors, not suggestions:**
+
+### 1. Session Start: Check for Context
+When beginning work on any project, **automatically search memory** for relevant context:
+```
+mcp__memory__search_nodes query: "{project-name}"
+mcp__memory__open_nodes names: ["user-eric"]
+```
+This takes 2 seconds and prevents re-learning what you already know.
+
+### 2. During Work: Store Decisions As They Happen
+When ANY of these occur, **immediately store without being asked**:
+
+| Event | Action |
+|-------|--------|
+| User states a preference | Store to `user-eric` entity |
+| Architectural decision made | Create `decision-{topic}` entity |
+| Bug root cause identified | Create `bug-{description}` entity |
+| Pattern chosen over alternatives | Create `pattern-{name}` with rationale |
+| User corrects your approach | Update `user-eric` with the correction |
+| Configuration choice with rationale | Create `decision-{topic}` entity |
+
+**Recognition patterns** - store when you hear:
+- "I prefer..." / "I like..." / "I always..." / "I never..."
+- "Let's go with X because..." / "We chose X over Y"
+- "The reason this failed was..." / "Root cause:"
+- "From now on..." / "Going forward..."
+- "That's not how we do it" / "Actually, we..."
+
+### 3. Session End: Capture Learnings
+Before ending significant sessions, consider:
+- What decisions were made that should persist?
+- What did you learn about the user's preferences?
+- What patterns or approaches worked well?
+- What should you remember for next time?
+
+### 4. Before Asking Questions You Might Already Know
+Before asking "What framework do you use?" or "How do you prefer X?", **check memory first**:
+```
+mcp__memory__search_nodes query: "preference"
+mcp__memory__search_nodes query: "{topic}"
+```
+
+## Entity Structure
+
+### Core Entities (create these)
+
+**User Entity** (singleton - add observations, don't recreate):
+```
+name: "user-eric"
+entityType: "user"
+observations:
+  - "Prefers FP patterns over OOP"
+  - "Anti-over-engineering philosophy"
+  - "Wants minimal code comments"
+  - "Uses Quasar for Vue projects"
+```
+
+**Project Entities**:
+```
+name: "project-{name}"
+entityType: "project"
+observations:
+  - "Tech stack: X, Y, Z"
+  - "Key patterns: ..."
+  - "Gotchas: ..."
+```
+
+**Decision Entities**:
+```
+name: "decision-{topic}"
+entityType: "decision"
+observations:
+  - "Chose X over Y"
+  - "Rationale: ..."
+  - "Made: {date}"
+  - "Applies to: {scope}"
+```
+
+### Relations (create these to build the graph)
+```
+user-eric → owns → project-imanetwork
+project-imanetwork → follows → decision-fp-patterns
+decision-fp-patterns → supersedes → decision-old-oop-approach
+```
+
+## Available Tools
+
+| Tool | When to Use |
+|------|-------------|
+| `search_nodes` | **First** - before creating, before asking user |
+| `open_nodes` | Load specific known entities |
+| `create_entities` | New project, decision, pattern, bug |
+| `add_observations` | New facts about existing entity |
+| `create_relations` | Connect related entities |
+| `read_graph` | Debug / audit (use sparingly) |
+| `delete_*` | Cleanup outdated information |
+
+## Quick Patterns
+
+### Store a user preference (do this automatically)
+```
+mcp__memory__search_nodes query: "user-eric"
+# If exists:
+mcp__memory__add_observations
+  observations: [{"entityName": "user-eric", "contents": ["Prefers early returns over nested conditionals"]}]
+# If not exists:
+mcp__memory__create_entities
+  entities: [{"name": "user-eric", "entityType": "user", "observations": ["..."]}]
+```
+
+### Store a decision with rationale
+```
+mcp__memory__create_entities
+  entities: [{
+    "name": "decision-validators-at-registration",
+    "entityType": "decision",
+    "observations": [
+      "IMA Forms: validators defined at field registration, not validation time",
+      "Rationale: single source of truth, template IS the definition",
+      "Made: 2026-01-15",
+      "Supersedes: separate validation schema approach"
+    ]
+  }]
+mcp__memory__create_relations
+  relations: [{"from": "project-ima-forms", "to": "decision-validators-at-registration", "relationType": "follows"}]
+```
+
+### Check before asking
+```
+# Instead of asking "What's your code style preference?"
+mcp__memory__search_nodes query: "code style"
+mcp__memory__search_nodes query: "preference"
+# Only ask if nothing found
+```
+
+## What NOT to Store
+
+- Temporary debugging steps
+- One-off fixes unlikely to recur
+- Information already in project docs (CLAUDE.md, README)
+- Sensitive data (credentials, API keys)
+
+## Naming Conventions
+
+| Prefix | Use |
+|--------|-----|
+| `user-{name}` | User preferences, corrections |
+| `project-{name}` | Project context, tech stack |
+| `decision-{topic}` | Architectural choices with rationale |
+| `pattern-{name}` | Reusable code patterns |
+| `bug-{description}` | Root causes worth remembering |
+| `standard-{topic}` | Team/org standards |
+
+## The Key Insight
+
+**Serena works because it's wired into code operations automatically.**
+**Memory works when it's wired into decision-making automatically.**
+
+Don't wait to be asked. When context flows through the conversation that should persist:
+1. Recognize it
+2. Store it
+3. Mention briefly: "I've noted your preference for X"
+
+This builds a knowledge graph that makes every future session better.

package/plugins/ima-claude/skills/mcp-qdrant/SKILL.md

@@ -0,0 +1,233 @@
+---
+name: mcp-qdrant
+description: "Qdrant MCP — the permanent library. Unlike Vestige (neural memory that fades), nothing stored here is ever forgotten. Use for all reference material: wiki articles, coding standards, architecture docs, code samples, PRDs, plans, meeting notes, research findings. Triggers on: 'store this', 'what do we know about', 'search knowledge', 'add to library', 'find in docs'. Triggers proactively when reference material is created, discussed, or finalized — feed the library without being asked. Search the library before starting any new work."
+---
+
+# Qdrant MCP - The Permanent Library
+
+Our permanent reference library. Unlike Vestige (neural memory that fades if unused), nothing stored here is ever forgotten. This is where we feed our entire universe — wiki articles, coding standards, architecture docs, code samples, PRDs, plans, and research findings.
+
+## Architecture: How This Fits
+
+| System | Role | Lifecycle | Example |
+|--------|------|-----------|---------|
+| **Qdrant** | Permanent library — reference material, standards, PRDs, architecture docs, code samples | Persistent forever | "Our payment system uses Accept.js with ARB" |
+| **Vestige** | Neural memory — decisions, preferences, patterns, bugs, learnings | Fades if unused (FSRS-6 decay) | "We chose JWT over sessions because..." |
+| **Serena Memory** | Project workbench — session state, task progress | Project-scoped, survives git ops | "Currently on task 3/5" |
+
+**Will it fade if we stop referencing it?** If no → Qdrant (permanent). If yes → Vestige (neural decay).
+
+## Embedding Stack
+
+| Component | Value |
+|---|---|
+| MCP server | `qdrant-mcp` (custom, at `~/dev/qdrant-mcp-server`) |
+| Embedding model | `nomic-embed-text` via Ollama |
+| Vector dimensions | 768 |
+| Distance metric | Cosine |
+| Vector type | Default (unnamed) |
+| Default collection | `ima-knowledge` |
+
+## Per-Project Collection
+
+Projects can specify their Qdrant collection via a `.qdrant` file in the project root (YAML format, like `.serena`):
+
+```yaml
+# .qdrant — project-level config
+collection: my-project-knowledge
+```
+
+**At session start**, check for a `.qdrant` file in the working directory. If found, read its `collection` value and pass it as `collection_name` on every `qdrant_store` and `qdrant_find` call for that session.
+
+If no `.qdrant` file is found, omit `collection_name` — the server defaults to `ima-knowledge` (from the `COLLECTION_NAME` env var).
+
+## MCP Tools
+
+MCP server name: `qdrant-memory`. Tool prefix: `mcp__qdrant-memory__`.
+
+| Tool | Purpose | Parameters |
+|------|---------|------------|
+| `qdrant_store` | Store text with auto-embedding | `information` (required), `collection_name`, `metadata` |
+| `qdrant_find` | Semantic search across stored knowledge | `query` (required), `collection_name`, `limit` |
+
+## Storing Knowledge
+
+```
+mcp__qdrant-memory__qdrant_store
+  information: "The IMA donation system uses Authorize.net Accept.js for payment
+    processing. Guest donations use charge-then-profile for ARB recurring."
+  metadata: {"source": "donation-system-prd", "type": "architecture", "date": "2026-02-21"}
+```
+
+To target a specific collection explicitly:
+
+```
+mcp__qdrant-memory__qdrant_store
+  collection_name: "other-project-knowledge"
+  information: "..."
+```
+
+### What to Store
+
+Anything that should never be forgotten — reference material for our permanent library.
+
+| Content Type | Metadata `type` |
+|---|---|
+| PRDs / Feature Specs | `prd` |
+| Architecture decisions & diagrams | `architecture` |
+| Integration guides | `integration` |
+| Domain knowledge | `domain` |
+| Requirements / meeting notes | `requirements` |
+| Coding standards & conventions | `standard` |
+| Useful code samples | `sample` |
+
+### Chunking Large Documents
+
+For documents over ~2000 words, store by section:
+
+```
+Store: "Donation System PRD - Overview: [content]"
+  metadata: {"source": "donation-prd", "type": "prd", "section": "overview"}
+
+Store: "Donation System PRD - Payment Flow: [content]"
+  metadata: {"source": "donation-prd", "type": "prd", "section": "payment-flow"}
+```
+
+Include the document title in each chunk so search results have context.
+
+## Searching Knowledge
+
+```
+mcp__qdrant-memory__qdrant_find
+  query: "how does guest recurring donation work"
+```
+
+**Broad**: `"payment processing"` — discover what's available
+**Specific**: `"Authorize.net ARB guest checkout"` — find exact knowledge
+**Problem-oriented**: `"SSO authentication between WordPress and Discourse"` — find solutions
+
+## Proactive Behavior
+
+### Feed the Library When:
+
+- A wiki article, PRD, or spec is created or discussed → store it
+- Architecture is documented or diagrammed → store it
+- A coding standard or convention is established → store it
+- A useful code sample is written → store it
+- Research is completed on a topic → store the findings
+- A Compound Engineering solution is finalized → store it
+- Integration is documented → store it
+- Meeting notes capture decisions or context → store them
+- User says "add this to knowledge base" or "store this"
+
+### Search the Library When:
+
+- Starting implementation of any feature → check if prior art exists
+- Debugging an integration → search for architecture context
+- User asks "how does X work" → check library before guessing
+- Planning new work → search for related PRDs or standards
+- Before making architectural decisions → search for existing conventions
+
+## Ingestion: Claude Web → Qdrant
+
+When user shares content from Claude Web Projects:
+
+1. User pastes document content
+2. For short docs (<2000 words): store as single entry
+3. For long docs: chunk by section with shared `source` metadata
+4. Confirm: "Stored [title] in knowledge base ([N] chunks)"
+
+## Decision Logic
+
+**Will it fade if we stop referencing it?** If no → store here. Qdrant is the permanent library.
+
+```
+IF reference material that should never be forgotten
+   (wiki, standards, PRDs, architecture docs, code samples, plans):
+    → Qdrant qdrant_store (permanent library)
+ELSE IF knowledge that should strengthen with use, fade if unused
+   (preferences, decisions, patterns, bugs):
+    → Vestige smart_ingest (neural memory)
+ELSE IF session state or project progress:
+    → Serena write_memory (project workbench)
+
+Searching:
+IF need reference docs, architecture context, prior art:
+    → Qdrant qdrant_find
+IF need user preferences or past decisions:
+    → Vestige search
+IF starting any new work:
+    → Search BOTH Qdrant and Vestige
+```
+
+## Metadata Conventions
+
+| Key | Values | Purpose |
+|-----|--------|---------|
+| `source` | Document name (kebab-case) | Group chunks from same doc |
+| `type` | `prd`, `architecture`, `integration`, `domain`, `requirements`, `standard`, `sample` | Categorize |
+| `date` | `YYYY-MM-DD` | When stored |
+
+## Error Recovery
+
+| Issue | Resolution |
+|-------|------------|
+| No results | Broaden query terms |
+| Irrelevant results | Use more specific key terms |
+| Qdrant not responding | `docker ps \| grep qdrant` — restart if needed |
+| Ollama not responding | `ollama list` — ensure it's running with `nomic-embed-text` |
+| Duplicate content | Search before storing to verify novelty |
+
+## When NOT to Use
+
+- Knowledge that should fade if unused (preferences, decisions, patterns) → Vestige (neural memory)
+- Session state or task progress → Serena memory (project workbench)
+- Code symbol search → Serena or Grep
+- Current web info → Tavily
+- Library API docs → Context7
+
+## Setup
+
+```bash
+# 1. Start Qdrant with persistent storage
+docker run -d --name qdrant \
+  -p 6333:6333 \
+  -v qdrant_storage:/qdrant/storage \
+  qdrant/qdrant:latest
+
+# 2. Install Ollama and pull embedding model
+ollama pull nomic-embed-text
+
+# 3. Install custom MCP server
+cd ~/dev/qdrant-mcp-server && pip install -e .
+
+# 4. Add to Claude Code (in ~/.claude.json mcpServers)
+# "qdrant-memory": {
+#   "type": "stdio",
+#   "command": "qdrant-mcp",
+#   "args": [],
+#   "env": {
+#     "QDRANT_URL": "http://localhost:6333",
+#     "COLLECTION_NAME": "ima-knowledge",
+#     "OLLAMA_URL": "http://localhost:11434",
+#     "EMBEDDING_MODEL": "nomic-embed-text"
+#   }
+# }
+
+# 5. Verify
+curl http://localhost:6333/health
+```
+
+**Persistence**: `-v qdrant_storage:/qdrant/storage` preserves data across restarts.
+**Embeddings**: Ollama with `nomic-embed-text` (768d). All data stays on your machine.
+
+### Per-Project Setup
+
+Add a `.qdrant` file to any project root to use a project-specific collection:
+
+```yaml
+# .qdrant
+collection: my-project-knowledge
+```
+
+This keeps project knowledge isolated from the global `ima-knowledge` collection. The collection is created automatically on first store.

package/plugins/ima-claude/skills/mcp-sequential/SKILL.md

@@ -0,0 +1,149 @@
+---
+name: "mcp-sequential"
+description: "Sequential Thinking MCP — use for debugging, root cause analysis, trade-off evaluation, architectural decisions, and any multi-step problem where the approach may need revision mid-stream. Triggers on: think through, step by step, debug this, figure out why, what's causing, root cause, troubleshoot, analyze, trade-offs, pros and cons, why is this failing, complex problem, design decision, how should we approach. Prevents expensive trial-and-error by structuring reasoning before acting."
+---
+
+# Sequential Thinking MCP - Structured Reasoning
+
+Use Sequential Thinking for complex problems that benefit from structured, revisable analysis.
+
+## Available Tool
+
+| Tool | Purpose |
+|------|---------|
+| `mcp__sequential-thinking__sequentialThinking` | Execute a thought in a reasoning chain |
+
+## When to Use
+
+**Use Sequential Thinking for:**
+- Breaking down complex problems into steps
+- Debugging issues where the cause isn't obvious
+- Architectural/design decisions with trade-offs
+- Problems where you might need to revise your approach
+- Multi-step analysis that needs context maintained
+- Filtering irrelevant information from complex scenarios
+- Hypothesis generation and verification
+
+**Don't use for:**
+- Simple, straightforward tasks
+- Questions with obvious answers
+- Tasks that don't require multi-step reasoning
+
+## Basic Usage
+
+Each call represents one thought in your reasoning chain.
+
+```
+mcp__sequential-thinking__sequentialThinking
+  thought: "First, let me understand the problem. We have X happening when Y..."
+  nextThoughtNeeded: true
+  thoughtNumber: 1
+  totalThoughts: 5
+```
+
+## Parameters
+
+| Parameter | Required | Description |
+|-----------|----------|-------------|
+| `thought` | Yes | Current thinking step content |
+| `nextThoughtNeeded` | Yes | `true` to continue, `false` when done |
+| `thoughtNumber` | Yes | Current step number (1, 2, 3...) |
+| `totalThoughts` | Yes | Estimated total (can adjust up/down) |
+| `isRevision` | No | `true` if revising previous thought |
+| `revisesThought` | No | Which thought number being revised |
+| `branchFromThought` | No | Thought number to branch from |
+| `branchId` | No | Identifier for the branch |
+
+## Continue Chain
+
+```
+mcp__sequential-thinking__sequentialThinking
+  thought: "Based on step 1, the likely cause is Z because..."
+  nextThoughtNeeded: true
+  thoughtNumber: 2
+  totalThoughts: 5
+```
+
+## Revise if Needed
+
+```
+mcp__sequential-thinking__sequentialThinking
+  thought: "Actually, my assumption in thought 2 was wrong. Let me reconsider..."
+  nextThoughtNeeded: true
+  thoughtNumber: 3
+  totalThoughts: 6
+  isRevision: true
+  revisesThought: 2
+```
+
+## Branch for Alternatives
+
+```
+mcp__sequential-thinking__sequentialThinking
+  thought: "Let me explore an alternative approach from step 2..."
+  nextThoughtNeeded: true
+  thoughtNumber: 4
+  totalThoughts: 7
+  branchFromThought: 2
+  branchId: "alternative-approach"
+```
+
+## Conclude
+
+```
+mcp__sequential-thinking__sequentialThinking
+  thought: "Based on my analysis, the solution is X because of Y and Z."
+  nextThoughtNeeded: false
+  thoughtNumber: 5
+  totalThoughts: 5
+```
+
+## Best Practices
+
+1. **Start with estimate, adjust as needed** - `totalThoughts` is flexible
+2. **Express uncertainty** - It's OK to say "I'm not sure, but..."
+3. **Revise freely** - Use `isRevision` when your understanding changes
+4. **Branch for alternatives** - Explore multiple approaches
+5. **Verify hypotheses** - Don't just guess, test your reasoning
+6. **Filter noise** - Focus on relevant information per step
+7. **Only conclude when confident** - Keep `nextThoughtNeeded: true` until satisfied
+
+## Example: Debugging a Bug
+
+```
+Thought 1: "The bug report says the form submits but data isn't saved. Let me identify possible failure points: 1) Frontend validation, 2) AJAX request, 3) Backend handler, 4) Database write."
+
+Thought 2: "Starting with the AJAX request - I should check if the request is being sent and what response comes back."
+
+Thought 3: "The request is sent but returns 500. So the issue is backend. Let me check the error logs."
+
+Thought 4: "Error log shows 'undefined index: email'. The frontend is sending 'user_email' but backend expects 'email'. This is a field name mismatch."
+
+Thought 5 (conclusion): "Root cause: Field name mismatch between frontend ('user_email') and backend ('email'). Solution: Update frontend to use 'email' or backend to accept 'user_email'."
+```
+
+## Example: Architecture Decision
+
+```
+Thought 1: "Need to decide between REST API and GraphQL for this project. Let me list the requirements: multiple clients, varying data needs, team experience."
+
+Thought 2: "REST pros: Team knows it well, simple caching, established patterns. Cons: Over-fetching for mobile, multiple endpoints."
+
+Thought 3: "GraphQL pros: Single endpoint, client specifies data needs, good for mobile. Cons: Learning curve, caching complexity."
+
+Thought 4 (revision): "Wait, I should also consider that we're using WordPress backend. REST is native to WordPress, GraphQL would need WPGraphQL plugin."
+
+Thought 5 (conclusion): "Recommendation: REST API. Reasons: 1) Native WordPress support, 2) Team expertise, 3) Simpler caching. The over-fetching concern can be mitigated with sparse fieldsets."
+```
+
+## Setup
+
+No API key required. Install with:
+```bash
+bun run scripts/setup-mcp.ts
+```
+
+Or manually:
+```bash
+claude mcp add --scope user sequential-thinking -- npx -y @modelcontextprotocol/server-sequential-thinking@latest
+```