@infinitedusky/indusk-mcp 0.6.2 → 0.7.1

package/package.json

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

package/skills/document.md

@@ -70,8 +70,7 @@ The `decisions/` and `lessons/` directories are **not** populated during normal
 
 - **One concept per diagram.** Don't cram the entire system into one chart. Break complex systems into focused diagrams.
 - **Meaningful labels.** Use full words, not abbreviations. `Plan Skill` not `PS`.
-- **Use `classDef` for visual grouping.** Color-code related nodes to show categories at a glance.
-- **Dark-mode friendly.** Avoid hardcoded light colors (white, light gray). Use the mermaid `dark` theme (already configured in VitePress). If you must customize colors, use high-contrast pairs.
+- **Do not use custom `style`, `classDef`, or `themeVariables` in diagrams.** The docs site supports both light and dark mode. The vitepress-plugin-mermaid auto-switches between Mermaid's `default` (light) and `dark` themes. Hardcoded colors (fills, text colors, borders) that work in one mode will be unreadable in the other. Let the built-in theme handle all colors. If you need visual grouping, use `subgraph` blocks instead of color-coding.
 - **Keep diagrams small enough to read inline** but detailed enough to be useful when expanded.
 
 ### Always Use FullscreenDiagram
@@ -118,6 +117,38 @@ implementation items → verification items → context items → document items
 
 A phase is not complete until its document items are done.
 
+## LLM-Readable Companion Files
+
+Every documentation page you create must have a corresponding **llms.txt** companion file. This makes the docs easy for AI agents to consume directly without HTML parsing.
+
+### How It Works
+
+For every page at `apps/indusk-docs/src/{path}.md`, create a matching file at `apps/indusk-docs/public/llms/{path}.txt`.
+
+```
+apps/indusk-docs/src/reference/skills/plan.md       → apps/indusk-docs/public/llms/reference/skills/plan.txt
+apps/indusk-docs/src/guide/getting-started.md        → apps/indusk-docs/public/llms/guide/getting-started.txt
+apps/indusk-docs/src/reference/tools/indusk-mcp.md   → apps/indusk-docs/public/llms/reference/tools/indusk-mcp.txt
+```
+
+### Content Rules
+
+The llms.txt file should contain the **same content** as the markdown page, with these adjustments:
+
+- Strip Mermaid diagram blocks and FullscreenDiagram wrappers (diagrams aren't useful as text)
+- Keep all tables, code blocks, headings, and prose
+- Keep all examples — these are the most valuable part for LLMs
+- Add a header line: `# {Page Title} — LLM-readable version`
+- Add a source line: `Source: {relative path to the .md file}`
+
+### Why
+
+When an external agent needs to understand this system, you can point it at `https://your-domain/llms/reference/skills/plan.txt` and it gets clean, structured text. No HTML parsing, no JavaScript rendering, no Mermaid SVGs to decode.
+
+### Also Create an Index
+
+Maintain `apps/indusk-docs/public/llms.txt` as a root index listing all available LLM-readable pages with their URLs and one-line descriptions. This follows the [llms.txt convention](https://llmstxt.org/).
+
 ## Running the Docs Site
 
 ```bash

package/skills/toolbelt.md

@@ -2,12 +2,20 @@
 
 You have MCP tools from two servers: **indusk** (dev system) and **codegraphcontext** (code graph). This skill tells you when to use them.
 
+## Lessons First
+
+The lesson system is how this project teaches you. Before writing any code, **always read the lessons**. They capture hard-won patterns and mistakes from past work — community-wide and personal.
+
+1. Call `list_lessons` at the start of every session. Read each one. These are not suggestions — they are rules this project has learned the hard way.
+2. When you discover a non-obvious pattern during work, capture it with `add_lesson`. Good lessons are actionable: they say what to do, why, and what goes wrong if you don't.
+3. During retrospectives, review whether any new lessons should be added based on what worked and what didn't.
+
 ## Session Start
 
 When a new session begins:
 
-1. Call `check_health` — verify FalkorDB and CGC are running. If unhealthy, tell the user what's down and how to fix it before proceeding.
-2. Call `list_lessons` — read all lessons (community + personal). Internalize these patterns before writing code.
+1. Call `list_lessons` — **read all lessons first**. Internalize these patterns before touching anything.
+2. Call `check_health` — verify FalkorDB and CGC are running. If unhealthy, tell the user what's down and how to fix it before proceeding.
 3. Call `list_plans` — understand what plans exist, their stages, and what's in progress.
 4. Call `get_context` — read the project's CLAUDE.md to understand architecture, conventions, and current state.