monomind 2.7.11 → 2.7.13

package/packages/@monomind/cli/.claude/commands/monograph/monograph-wiki.md

@@ -1,91 +0,0 @@
----
-name: monograph:monograph-wiki
-description: Scan all docs and PDFs and build a searchable knowledge graph — optimized for documentation-heavy projects with Claude LLM semantic extraction
----
-
-# monograph wiki
-
-Scan all docs and PDFs in the project and build a searchable knowledge graph. Optimized for documentation-heavy projects.
-
-## Usage
-
-```bash
-npx monomind monograph wiki [options]
-```
-
-## Options
-
-| Flag | Short | Type | Default | Description |
-|---|---|---|---|---|
-| `--path` | `-p` | string | cwd | Root path to scan |
-| `--llm` | — | boolean | `false` | Enrich with Claude semantic extraction (requires `ANTHROPIC_API_KEY`) |
-| `--llm-sections` | — | number | `100` | Max sections for LLM enrichment |
-| `--force` | `-f` | boolean | `false` | Force full rebuild |
-
-## Examples
-
-```bash
-# Build knowledge graph from all docs and PDFs
-npx monomind monograph wiki
-
-# With Claude semantic extraction
-npx monomind monograph wiki --llm
-
-# Deep enrichment — process 200 sections with Claude
-npx monomind monograph wiki --llm --llm-sections 200
-
-# Specific docs folder
-npx monomind monograph wiki -p ./docs
-
-# Force full rebuild
-npx monomind monograph wiki --force
-```
-
-## What Gets Indexed
-
-Scans for files with extensions: `.md`, `.mdx`, `.txt`, `.rst`, `.pdf`
-
-| Type | Processing |
-|---|---|
-| `.md` / `.mdx` | Headings → `Section` nodes with hierarchical structure |
-| `.txt` / `.rst` | Chunked → `Section` nodes |
-| `.pdf` | Text extracted → PDF chunk nodes |
-
-## Difference from `build`
-
-| | `build` | `wiki` |
-|---|---|---|
-| Code files | Yes | No |
-| Documents | Yes | Yes |
-| PDFs | Yes | Yes |
-| LLM default sections | 50 | 100 |
-| Best for | Mixed projects | Doc-heavy / knowledge bases |
-
-## LLM Enrichment
-
-With `--llm`, Claude extracts semantic relationships between sections:
-- `DESCRIBES` — section explains a concept
-- `CAUSES` — one event leads to another
-- `PART_OF` — hierarchical membership
-- `CO_OCCURS` — concepts appear together
-
-These `INFERRED` edges make semantic search significantly more accurate.
-
-## After Build
-
-```bash
-# Search your wiki
-npx monomind monograph search -q "your query"
-
-# View statistics
-npx monomind monograph stats
-
-# Auto-rebuild on edits
-npx monomind monograph watch
-```
-
-## See Also
-
-- `monograph build` — full build including code files
-- `monograph search` — search the graph
-- `monograph stats` — node/edge breakdown

package/packages/@monomind/cli/.claude/commands/optimization/auto-topology.md

@@ -1,85 +0,0 @@
----
-name: optimization:auto-topology
-description: Automatically select the optimal swarm topology based on task complexity — use pre-task hook recommendations, swarm init flags, and performance optimize CLI
----
-
-# Auto Topology Selection
-
-Automatically select the optimal swarm topology based on task complexity so you don't have to configure it manually.
-
-## How It Works
-
-### 1. Get a Routing Recommendation
-
-Before spawning agents, run the `pre-task` hook. It analyzes task complexity and recommends a topology:
-
-```bash
-npx monomind hooks pre-task -d "Refactor authentication system with JWT, add tests, update docs"
-```
-
-Output includes agent and topology suggestions.
-
-### 2. Initialize the Swarm With the Recommended Topology
-
-```bash
-# Simple/medium tasks — hierarchical (anti-drift, tight control)
-npx monomind swarm init --topology hierarchical --max-agents 6 --strategy specialized
-
-# Complex multi-domain tasks — hierarchical-mesh (peer communication + queen)
-npx monomind swarm init --topology hierarchical-mesh --max-agents 12 --strategy specialized
-```
-
-### Topology Selection Guide
-
-| Complexity | Agents Needed | Recommended Topology |
-|---|---|---|
-| Simple (single file) | 1–2 | `star` — skip swarm, use Edit tool directly |
-| Medium | 3–5 | `hierarchical` |
-| Complex (multi-module) | 6–8 | `hierarchical` |
-| Large (10+ agents) | 10–15 | `hierarchical-mesh` |
-| Sequential pipeline | any | `ring` |
-
-## Optimize Existing Swarm Topology
-
-If a swarm is already running, optimize its topology via the coordination MCP tool:
-
-```javascript
-mcp__monomind__coordination_topology({
-  swarmId: "current",
-  optimize: true
-})
-```
-
-Or via the performance CLI:
-
-```bash
-# Analyze and recommend optimizations (dry run)
-npx monomind performance optimize --target all --dry-run
-
-# Apply recommended optimizations
-npx monomind performance optimize --target all --apply
-```
-
-## Hook Integration
-
-`pre-task` fires automatically if wired in `settings.json`:
-
-```json
-{
-  "hooks": {
-    "PreToolUse": [{
-      "matcher": "^Task$",
-      "hooks": [{
-        "type": "command",
-        "command": "npx monomind hooks pre-task -d '${tool.params.description}'"
-      }]
-    }]
-  }
-}
-```
-
-## See Also
-
-- `swarm init` — initialize swarm with explicit topology
-- `performance optimize` — system-level performance tuning
-- `hooks pre-task` — get routing and topology recommendations

package/packages/@monomind/cli/.claude/commands/optimization/performance-optimize.md

@@ -1,79 +0,0 @@
----
-name: optimization:performance-optimize
-description: Analyze and apply system-level performance optimizations — memory, CPU, and latency using npx monomind performance optimize
----
-
-# performance optimize
-
-Analyze and apply system-level performance optimizations — memory, CPU, and latency.
-
-## Usage
-
-```bash
-npx monomind performance optimize [options]
-```
-
-## Options
-
-| Flag | Short | Type | Default | Description |
-|---|---|---|---|---|
-| `--target` | `-t` | string | `all` | Optimization target: `memory`, `cpu`, `latency`, `all` |
-| `--apply` | `-a` | boolean | `false` | Apply recommended optimizations |
-| `--dry-run` | `-d` | boolean | `false` | Show recommended changes without applying |
-
-## Examples
-
-```bash
-# Analyze and show recommendations (no changes)
-npx monomind performance optimize --dry-run
-
-# Optimize everything and apply
-npx monomind performance optimize --target all --apply
-
-# Memory-specific optimization
-npx monomind performance optimize --target memory --apply
-
-# CPU optimization only
-npx monomind performance optimize --target cpu --apply
-
-# Latency optimization (MCP response time)
-npx monomind performance optimize --target latency --apply
-```
-
-## Optimization Targets
-
-| Target | What It Optimizes |
-|---|---|
-| `memory` | Memory backend compression, HNSW rebuild, cache eviction |
-| `cpu` | Agent pool sizing, task batching, concurrency limits |
-| `latency` | MCP response caching, neural model quantization |
-| `all` | All of the above |
-
-## Related Commands
-
-```bash
-# Find bottlenecks before optimizing
-npx monomind performance bottleneck
-
-# Run benchmarks to measure before/after
-npx monomind performance benchmark --suite all
-
-# View current performance metrics
-npx monomind performance metrics
-```
-
-## MCP Tool
-
-```javascript
-mcp__monomind__performance_optimize({
-  target: "all",
-  apply: false
-})
-```
-
-## See Also
-
-- `performance bottleneck` — diagnose what to optimize first
-- `performance benchmark` — measure optimization impact
-- `performance metrics` — track performance over time
-- `neural optimize` — optimize neural model weights

package/packages/@monomind/cli/.claude/commands/pair/README.md

@@ -1,79 +0,0 @@
----
-name: pair:README
-description: Pair programming with Claude Code — driver/navigator modes, TDD sessions, review sessions, Task tool agent spawning, and hooks integration
----
-
-# Pair Programming with Claude Code
-
-Collaborative development using Claude Code as your AI pair partner. No special CLI needed — Claude Code IS the pair partner.
-
-## How It Works
-
-Pair programming with Claude Code means structuring your conversation to get the most out of the collaboration. Depending on your goal, you drive or Claude drives.
-
-## Quick Start
-
-**You drive, Claude reviews (driver mode):**
-> "I'm going to implement JWT auth. Review my approach and flag issues as we go."
-
-**Claude drives, you guide (navigator mode):**
-> "Implement a JWT auth middleware for Express with refresh token support. I'll review each piece."
-
-**TDD session:**
-> "Let's do TDD for this shopping cart feature. Write the failing tests first, then we'll implement."
-
-**Review session:**
-> "Review all the changes I've made today to `src/auth/`. Focus on security issues."
-
-## Using the Pair Programming Skill
-
-Invoke the `pair-programming` skill for structured collaboration:
-
-```
-/pair-programming
-```
-
-This loads the workflow guide and sets up the session context.
-
-## Spawning a Specialized Agent
-
-For long-running or complex sessions, spawn a dedicated coding agent via the Task tool:
-
-```javascript
-Task({
-  prompt: "Act as a senior developer pair programming partner. The user is implementing JWT auth. Review their code as they write it, suggest improvements, catch issues, and explain patterns. Start by asking what they want to build.",
-  subagent_type: "Senior Developer",
-  run_in_background: false
-})
-```
-
-Or use a specific specialist:
-- `superpowers:test-driven-development` — TDD-focused pairing
-- `superpowers:systematic-debugging` — debugging sessions
-- `superpowers:receiving-code-review` — code review sessions
-
-## Hooks Integration
-
-Use hooks to track pair session quality:
-
-```bash
-# Register session start
-npx monomind hooks pre-task -d "Pair programming: implement JWT auth"
-
-# After session, record outcome
-npx monomind hooks post-task --task-id <id> --success true --quality 0.95
-```
-
-## Files
-
-- [modes.md](./modes.md) — Driver, navigator, TDD, review, debug modes
-- [session.md](./session.md) — Session lifecycle and real monitoring commands
-- [examples.md](./examples.md) — Real-world pair programming scenarios
-
-## See Also
-
-- `superpowers:pair-programming` — structured pair programming skill
-- `superpowers:test-driven-development` — TDD workflow
-- `superpowers:systematic-debugging` — debugging workflow
-- `superpowers:requesting-code-review` — code review workflow
-- `hooks pre-task` — register task start and get recommendations

package/packages/@monomind/cli/.claude/commands/pair/examples.md

@@ -1,156 +0,0 @@
----
-name: pair:examples
-description: Real-world pair programming scenarios — JWT auth, memory leak debugging, TDD, code review, and refactoring with effective prompt patterns
----
-
-# Pair Programming Examples
-
-Real-world scenarios with actual Claude Code patterns — no fictional CLI.
-
----
-
-## Example 1: Feature Implementation (Navigator Mode)
-
-**Goal:** Implement JWT authentication with refresh tokens.
-
-**Setup:**
-```bash
-npx monomind hooks pre-task -d "Implement JWT auth with refresh tokens"
-```
-
-**Session:**
-
-> "Implement JWT auth middleware for Express. Include: access token (15min expiry), refresh token (7 days), token rotation on refresh, and blacklisting revoked tokens. Start with the token generation utilities, then we'll do the middleware."
-
-Claude implements. Review each piece:
-
-> "Good. One issue: store refresh tokens in Redis, not in-memory. Update that before continuing."
-
-After middleware is done:
-
-> "Now write unit tests for the token generation utilities. Use Jest. Cover: valid tokens, expired tokens, tampered tokens, and token rotation."
-
-End:
-> "Summarize what we built and what's still needed before this is production-ready."
-
-```bash
-npx monomind hooks post-task --task-id <id> --success true --quality 0.9
-```
-
----
-
-## Example 2: Debugging (Debug Mode)
-
-**Goal:** Memory leak in a Node.js service.
-
-**Setup:**
-```
-Skill("superpowers:systematic-debugging")
-```
-
-Or directly:
-
-> "Debug session: our Node.js service leaks memory — grows from 150MB to 450MB over 10 minutes, then crashes. I'll share code as needed. Start by asking me questions to narrow down the cause."
-
-Claude asks targeted questions. You share relevant code sections.
-
-> "Here's the event emitter setup: [paste code]"
-
-> "Found it: EventEmitter listeners aren't removed on cleanup. Show me the fix and explain why this pattern causes the leak."
-
-Apply the fix, verify:
-
-> "Fixed. Write a test that would have caught this — one that monitors memory over time or checks listener counts."
-
----
-
-## Example 3: TDD (TDD Mode)
-
-**Goal:** Shopping cart feature, test-first.
-
-**Setup:**
-```
-Skill("superpowers:test-driven-development")
-```
-
-Or:
-
-> "TDD session: shopping cart. Write failing tests first for: add item, remove item, update quantity, calculate total, apply discount. Then I'll implement each. Don't write implementation code — just tests."
-
-**Red phase:** Claude writes failing tests. You read and understand each.
-
-**Green phase:** You implement just enough to pass.
-
-> "Tests passing. Now refactor the total calculation — it's too long."
-
-Claude refactors. You verify tests still pass.
-
-> "Next cycle: write failing tests for the discount system."
-
----
-
-## Example 4: Code Review (Review Mode)
-
-**Goal:** Review a PR diff before merging.
-
-**Setup:**
-```bash
-git diff main...feat/auth > /tmp/auth-diff.txt
-```
-
-> "Review this PR. File: `src/auth/middleware.ts`. Rate: (1) correctness, (2) security vulnerabilities, (3) error handling, (4) test coverage. List issues as: [CRITICAL] / [MAJOR] / [MINOR] with file+line."
-
-Review output guides your fixes. For each CRITICAL issue:
-
-> "Fix #2 (JWT secret in code). Show me the corrected version."
-
-After applying fixes:
-
-> "Any remaining issues worth fixing before merge?"
-
----
-
-## Example 5: Refactoring (Driver Mode)
-
-**Goal:** Modernize callback-heavy code to async/await.
-
-> "Driver mode: I'm refactoring `UserService.js` from callbacks to async/await. Watch what I change and flag if I miss anything or introduce bugs. I'll share the original first."
-
-Paste the original code.
-
-> "Here's the original getUserById. I'm changing it to async/await now."
-
-Paste your refactored version.
-
-Claude reviews: "Looks good, but you're missing error handling on the database call. Add a try/catch."
-
-Continue through each function.
-
-At end:
-
-> "Final check: any patterns in the refactored code that should be extracted into utilities?"
-
----
-
-## Effective Prompts Reference
-
-| Situation | Prompt |
-|---|---|
-| Start navigator mode | "Implement [X]. I'll review each section before you continue." |
-| Start driver mode | "I'm implementing [X]. Review as I share code and flag issues." |
-| Start TDD | "Write failing tests for [X] first. I'll implement after." |
-| Start review | "Review [file/diff]. Focus on [concern]. Rate and list issues." |
-| Start debug | "Debug [symptom]. Ask me questions to narrow down the cause." |
-| Switch mode | "Now you drive — implement [next piece] based on what we've discussed." |
-| Mid-session check | "Before we continue: summarize state and confirm the next step." |
-| End session | "Summarize: what we built, decisions made, what's left." |
-| Get unstuck | "I'm not sure how to handle [edge case]. What are the options?" |
-| Pattern question | "Is this the right pattern here, or is there a better approach?" |
-
-## See Also
-
-- [modes.md](./modes.md) — choosing the right mode
-- [session.md](./session.md) — session lifecycle and tracking
-- `superpowers:pair-programming` — structured pair programming skill
-- `superpowers:test-driven-development` — full TDD workflow
-- `superpowers:systematic-debugging` — debugging methodology

package/packages/@monomind/cli/.claude/commands/pair/modes.md

@@ -1,122 +0,0 @@
----
-name: pair:modes
-description: Pair programming collaboration modes — driver, navigator, TDD, review, and debug modes with effective prompts for each
----
-
-# Pair Programming Modes
-
-Different collaboration patterns for different goals. Choose based on what you're trying to accomplish.
-
-## Driver Mode — You Write, Claude Reviews
-
-You do the coding. Claude watches, suggests, and catches issues in real time.
-
-**Start it:**
-> "I'm implementing [feature]. Watch what I'm building and review each piece as I share it. Point out issues, security problems, and improvements."
-
-**Best for:**
-- Learning new patterns (you get hands-on + feedback)
-- Implementing features you understand but want reviewed
-- Debugging when you have a hypothesis to test
-
-**Effective prompts during driver mode:**
-- "Here's what I wrote — what do you think?"
-- "I'm about to add validation here. Any pitfalls?"
-- "Is this the right pattern for this situation?"
-- "Review this function before I move on."
-
----
-
-## Navigator Mode — Claude Writes, You Guide
-
-Claude does the coding. You provide direction, review output, and control architecture decisions.
-
-**Start it:**
-> "Implement [feature]. I'll guide the direction and review each section before you move on. Start with [specific first piece]."
-
-**Best for:**
-- Rapid prototyping
-- Boilerplate and scaffolding
-- Exploring approaches you haven't used before
-- Getting unstuck quickly
-
-**Effective prompts during navigator mode:**
-- "Implement X. Use [pattern/library]."
-- "That's good but change [specific thing]."
-- "Before writing the next piece, explain your approach."
-- "Show me an alternative approach to this."
-
----
-
-## TDD Mode — Tests First
-
-Write failing tests, then implement just enough to pass, then refactor.
-
-**Start it:**
-> "We're doing TDD for [feature]. Write the failing tests first, explain what each test covers, then I'll implement. We refactor together after tests pass."
-
-**The cycle:**
-1. Claude writes a failing test — you understand it
-2. You implement minimal passing code
-3. Claude reviews the implementation
-4. Together you refactor
-5. Repeat
-
-**Invoke the TDD skill for full workflow:**
-```
-Skill("superpowers:test-driven-development")
-```
-
----
-
-## Review Mode — Quality Focus
-
-Work through existing code with Claude as reviewer.
-
-**Start it:**
-> "Review the changes in `src/auth/`. Focus on [security / correctness / performance]. Be specific about issues — give file, line, and explanation."
-
-**Structured review request:**
-> "Review this PR diff. Rate it on: (1) correctness, (2) security, (3) readability, (4) test coverage. List issues by severity."
-
-**Invoke the review skill:**
-```
-Skill("superpowers:requesting-code-review")
-```
-
----
-
-## Debug Mode — Problem Solving
-
-Systematic debugging as a pair.
-
-**Start it:**
-> "We have a bug: [describe symptom]. Let's debug together. Start by asking me questions to narrow down the cause."
-
-**Invoke the debugging skill:**
-```
-Skill("superpowers:systematic-debugging")
-```
-
----
-
-## Switching Modes
-
-You can switch modes at any point just by redirecting:
-
-> "Let's switch — now you drive. Implement the auth middleware based on what we've discussed."
-
-> "Actually let me write this part. Review as I go."
-
-> "Stop implementing — let's do TDD for the rest of this."
-
-## Mode Selection Guide
-
-| Goal | Mode |
-|---|---|
-| Learning + control | Driver |
-| Speed + generation | Navigator |
-| Quality from the start | TDD |
-| Fix existing code | Review |
-| Fix a bug | Debug |
-| Long complex feature | Switch (start navigator, finish driver) |