@infinitedusky/indusk-mcp 0.6.2 → 0.7.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@infinitedusky/indusk-mcp",
3
- "version": "0.6.2",
3
+ "version": "0.7.0",
4
4
  "description": "InDusk development system — skills, MCP tools, and CLI for structured AI-assisted development",
5
5
  "type": "module",
6
6
  "files": [
@@ -118,6 +118,38 @@ implementation items → verification items → context items → document items
118
118
 
119
119
  A phase is not complete until its document items are done.
120
120
 
121
+ ## LLM-Readable Companion Files
122
+
123
+ 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.
124
+
125
+ ### How It Works
126
+
127
+ For every page at `apps/indusk-docs/src/{path}.md`, create a matching file at `apps/indusk-docs/public/llms/{path}.txt`.
128
+
129
+ ```
130
+ apps/indusk-docs/src/reference/skills/plan.md → apps/indusk-docs/public/llms/reference/skills/plan.txt
131
+ apps/indusk-docs/src/guide/getting-started.md → apps/indusk-docs/public/llms/guide/getting-started.txt
132
+ apps/indusk-docs/src/reference/tools/indusk-mcp.md → apps/indusk-docs/public/llms/reference/tools/indusk-mcp.txt
133
+ ```
134
+
135
+ ### Content Rules
136
+
137
+ The llms.txt file should contain the **same content** as the markdown page, with these adjustments:
138
+
139
+ - Strip Mermaid diagram blocks and FullscreenDiagram wrappers (diagrams aren't useful as text)
140
+ - Keep all tables, code blocks, headings, and prose
141
+ - Keep all examples — these are the most valuable part for LLMs
142
+ - Add a header line: `# {Page Title} — LLM-readable version`
143
+ - Add a source line: `Source: {relative path to the .md file}`
144
+
145
+ ### Why
146
+
147
+ 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.
148
+
149
+ ### Also Create an Index
150
+
151
+ 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/).
152
+
121
153
  ## Running the Docs Site
122
154
 
123
155
  ```bash
@@ -2,12 +2,20 @@
2
2
 
3
3
  You have MCP tools from two servers: **indusk** (dev system) and **codegraphcontext** (code graph). This skill tells you when to use them.
4
4
 
5
+ ## Lessons First
6
+
7
+ 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.
8
+
9
+ 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.
10
+ 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.
11
+ 3. During retrospectives, review whether any new lessons should be added based on what worked and what didn't.
12
+
5
13
  ## Session Start
6
14
 
7
15
  When a new session begins:
8
16
 
9
- 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.
10
- 2. Call `list_lessons` — read all lessons (community + personal). Internalize these patterns before writing code.
17
+ 1. Call `list_lessons` — **read all lessons first**. Internalize these patterns before touching anything.
18
+ 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.
11
19
  3. Call `list_plans` — understand what plans exist, their stages, and what's in progress.
12
20
  4. Call `get_context` — read the project's CLAUDE.md to understand architecture, conventions, and current state.
13
21