@infinitedusky/indusk-mcp 1.0.2 → 1.1.0

package/dist/bin/commands/extensions.js

@@ -1,5 +1,5 @@
 import { execSync } from "node:child_process";
-import { cpSync, existsSync, mkdirSync, readdirSync, readFileSync, rmSync, writeFileSync } from "node:fs";
+import { cpSync, existsSync, mkdirSync, readdirSync, readFileSync, rmSync, writeFileSync, } from "node:fs";
 import { dirname, join } from "node:path";
 import { fileURLToPath } from "node:url";
 import { globSync } from "glob";

package/extensions/falkordb/manifest.json

@@ -13,7 +13,7 @@
 		}
 	},
 	"hooks": {
-		"on_init": "docker start falkordb 2>/dev/null || docker run -d --name falkordb --restart unless-stopped -v falkordb-global:/data falkordb/falkordb:latest",
+		"on_init": "docker start falkordb 2>/dev/null || docker run -d --name falkordb --restart unless-stopped -v falkordb-global:/var/lib/falkordb/data falkordb/falkordb:latest",
 		"on_health_check": "docker ps --filter name=falkordb --format '{{.Status}}'"
 	}
 }

package/lessons/community/community-mount-to-actual-data-dir.md

@@ -0,0 +1,7 @@
+# Mount Docker volumes to the actual data directory
+
+When creating a Docker container with a persistent volume, verify where the application actually writes data — don't assume `/data`.
+
+FalkorDB writes to `/var/lib/falkordb/data/`, not `/data`. Mounting a volume to `/data` captures an empty directory with a symlink, not the actual data. On container recreation, the data is gone.
+
+Always check the image's actual data path before creating the volume mount. `docker exec <container> ls -la /data/` will show you if it's a symlink to somewhere else.

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "@infinitedusky/indusk-mcp",
-	"version": "1.0.2",
+	"version": "1.1.0",
 	"description": "InDusk development system — skills, MCP tools, and CLI for structured AI-assisted development",
 	"type": "module",
 	"files": [

package/skills/{onboard.md → catchup.md}

@@ -1,19 +1,30 @@
 ---
-name: onboard
-description: Get a new agent caught up on the project. Reads context, plans, lessons, and code graph health in one shot. Run at the start of every new session.
+name: catchup
+description: Get caught up on the project. Reads the handoff from the last session, then context, plans, lessons, extensions, and code graph. Run at the start of every new session.
 ---
 
 You are starting a new session on this project. Before doing anything else, get caught up.
 
 ## Steps (execute in order)
 
-### 1. Read Lessons
+### 1. Read Handoff
+Check if `.claude/handoff.md` exists. If it does, read it first — this is the most recent context from the last session. It tells you:
+- What was being worked on
+- Where it stopped
+- What's next
+- Any warnings or open issues
+
+If the handoff exists, present a brief summary to the user: "Last session was working on X, stopped at Y. Ready to pick up there?"
+
+If no handoff exists, skip to step 2.
+
+### 2. Read Lessons
 Call `list_lessons`. Read every lesson. These are rules learned from past mistakes — not suggestions. Internalize them before touching any code.
 
-### 2. Check Infrastructure
+### 3. Check Infrastructure
 Call `check_health`. Verify FalkorDB and CGC are running. If unhealthy, tell the user what's down and how to fix it.
 
-### 3. Read Project Context
+### 4. Read Project Context
 Call `get_context` to read CLAUDE.md. This contains:
 - **Architecture** — what the project is, how it's structured
 - **Conventions** — rules to follow (commit style, no DB from Next.js, no fallback URLs, etc.)
@@ -23,39 +34,40 @@ Call `get_context` to read CLAUDE.md. This contains:
 
 Read it fully. Don't skim.
 
-### 4. Check Active Plans
+### 5. Check Active Plans
 Call `list_plans`. This shows every plan and its status. Pay attention to:
 - Plans with status `in-progress` — these are actively being worked on
 - The current phase of each active plan — this is where `/work` will pick up
 - Dependencies between plans — don't start a blocked plan
 
-### 5. Check Extensions
+### 6. Check Extensions
 Call `extensions_status` to see what extensions are enabled and their capabilities. This tells you what tools are integrated and what domain knowledge is available.
 
-### 6. Check Code Graph
+### 7. Check Code Graph
 Call `get_repository_stats` to understand the codebase size and structure. This gives you a sense of what's indexed and queryable. If it fails, the CGC extension may not be enabled or FalkorDB may be down — check_health will have flagged this.
 
-### 7. Summarize
+### 8. Summarize
 
-After completing steps 1-6, present a brief summary to the user:
+After completing all steps, present a brief summary to the user:
 
 ```
-**Session ready.**
+**Caught up.**
+- Handoff: [summary of last session's work, or "none"]
 - Lessons: N loaded
 - Infrastructure: [healthy / issues]
 - Extensions: N enabled [list names]
 - Active plans: [list with current phase]
 - Codebase: [N files indexed]
 
-Ready to work. What would you like to do?
+Ready to pick up. What would you like to do?
 ```
 
 ## When to Use
 
 - Start of every new Claude Code session
-- When the user says "get caught up", "what's going on", "where are we"
+- When the user says "get caught up", "what's going on", "where are we", "catch up"
 - When context was compressed and you need to re-orient
-- `/onboard` explicitly
+- `/catchup` explicitly
 
 ## Important
 

package/skills/handoff.md

@@ -0,0 +1,50 @@
+---
+name: handoff
+description: Write a handoff file before ending a session. Captures what was worked on, where it stopped, what's next, and any warnings for the next agent.
+---
+
+You are ending a session or handing off to another agent. Write a handoff file so the next session can pick up exactly where you left off.
+
+## What to Write
+
+Create or overwrite `.claude/handoff.md` with:
+
+```markdown
+# Handoff
+
+**Date:** {YYYY-MM-DD}
+**Session:** {brief description of what this session focused on}
+
+## What Was Being Worked On
+{Plan name, phase, specific checklist item. Be precise — "Phase 3 of extension-system, item 4: refactor check_health" not "working on extensions."}
+
+## Where It Stopped
+{Last thing completed. First thing that needs doing next. If mid-item, explain exactly where.}
+
+## What's Next
+{The immediate next step. Then the next 2-3 steps after that. This is the pickup point for /catchup.}
+
+## Open Issues
+{Anything broken, failing, or weird. Tests that don't pass. Errors being investigated. Things that worked before but don't now.}
+
+## Decisions Made This Session
+{Any decisions that aren't captured in CLAUDE.md or an ADR yet. These need to be formalized — they're here so they don't get lost between sessions.}
+
+## Watch Out For
+{Gotchas the next agent should know. "The FalkorDB graph needs reindexing." "The hooks aren't published yet — version 1.0.3 has them." "Don't touch init.ts until the extension system PR is merged."}
+```
+
+## When to Write a Handoff
+
+- Before ending any session where work was done
+- When the user says "let's stop here", "wrap up", "hand off"
+- When you're about to run out of context
+- `/handoff` explicitly
+
+## Rules
+
+- **Be specific.** "Working on Phase 3" is useless. "Phase 3, item 4: refactored check_health to use extensions. extensions_status MCP tool created. Next: refactor init to remove hardcoded FalkorDB/CGC." is useful.
+- **Include the ugly parts.** If something is broken, say so. The next agent needs to know.
+- **Decisions that aren't saved anywhere else MUST go here.** They'll be lost otherwise.
+- **Overwrite the previous handoff.** There's only one — the most recent session's. Old handoffs are consumed by /catchup and don't need to persist.
+- **Keep it short.** This isn't a retrospective. It's a sticky note for the next person.