@sandrinio/vdoc 3.5.2 → 3.6.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/README.md CHANGED
@@ -47,30 +47,48 @@ Then open Cursor and type: **`/vdoc init`**
47
47
 
48
48
  ## How It Works
49
49
 
50
+ vdoc is **plan-first**. The AI proposes — you decide. Nothing gets generated until you approve.
51
+
50
52
  ### 1. Install (~5 seconds)
51
53
 
52
54
  ```bash
53
55
  npx @sandrinio/vdoc install claude
54
56
  ```
55
57
 
56
- Copies skill files to your AI platform's rules and commands locations. That's it.
58
+ Copies skill files to your AI platform's config. No dependencies, no build step.
59
+
60
+ ### 2. Init — `/vdoc-init`
61
+
62
+ This is the main workflow. Type `/vdoc-init` (or say "document this project") and the AI runs through four phases:
63
+
64
+ **Phase 1: Explore** — The AI reads your project's config files and directory structure to identify the language, framework, and architecture. It uses archetype-based strategies (Web API, SPA, Full-Stack, CLI, Library, etc.) to know exactly which files to scan. The result is an exploration log documenting every file read and every feature signal detected.
65
+
66
+ **Phase 2: Plan** — Based on what it found, the AI creates a documentation plan — a list of proposed docs, each covering one logical feature (not one file). The plan is saved as a file you can review.
67
+
68
+ **Phase 3: You review** — The AI presents the plan and asks for your input:
69
+ - *"Should I merge API routes and middleware into one doc?"*
70
+ - *"I found a websocket system — want that documented separately?"*
71
+ - *"Any legacy systems I should skip?"*
72
+
73
+ You can add, remove, rename, or restructure docs before approving. **Nothing is generated until you say go.**
57
74
 
58
- ### 2. Init
75
+ **Phase 4: Generate** — For each approved doc, the AI reads all relevant source files, follows a consistent template, and writes feature-centric documentation with mermaid diagrams, real code references, and a semantic manifest for future AI queries.
59
76
 
60
- Type **`/vdoc-init`** in your AI tool (or say "document this project"). The skill tells the AI to:
77
+ ### 3. Update `/vdoc-update`
61
78
 
62
- 1. **Explore** identify features, tech stack, architecture
63
- 2. **Plan** — propose a documentation plan for your approval
64
- 3. **Generate** — create feature-centric docs using a consistent template
65
- 4. **Index** — build a semantic manifest for future queries
79
+ Type `/vdoc-update` (or `/vdoc-audit`) when your code has changed. The AI:
66
80
 
67
- ### 3. Update
81
+ 1. Checks git history to find which source files changed since docs were last updated
82
+ 2. Cross-references changes against each doc's "Key Files" to identify stale docs
83
+ 3. Scans for new features not covered by any doc
84
+ 4. Flags dead docs whose source files were deleted
85
+ 5. Verifies cross-references between docs
68
86
 
69
- Type **`/vdoc-update`** (or say "update docs"). The AI detects what changed via git, finds coverage gaps, flags dead docs, checks cross-references, reports everything, and patches only what you approve.
87
+ It presents a report and waits for your direction before patching anything.
70
88
 
71
- ### 4. Create
89
+ ### 4. Create — `/vdoc-create <feature>`
72
90
 
73
- Type **`/vdoc-create authentication system`** to document a single feature on demand. The AI locates the relevant source files, generates one doc, and updates the manifest.
91
+ Type `/vdoc-create authentication system` to document a single feature on demand. The AI locates the relevant source files, generates one doc following the same template, and updates the manifest. Useful for adding docs incrementally without re-running the full init.
74
92
 
75
93
  ---
76
94
 
@@ -97,6 +115,38 @@ Docs are **feature-centric** — organized by what your system does, not by file
97
115
 
98
116
  ---
99
117
 
118
+ ## The Workflow
119
+
120
+ ```
121
+ ┌─────────────────────────────────────────────────────────┐
122
+ │ /vdoc-init │
123
+ │ │
124
+ │ Explore ──→ Plan ──→ You Review ──→ Generate │
125
+ │ (auto) (auto) (you decide) (auto) │
126
+ │ │ │
127
+ │ add / remove / rename │
128
+ │ merge / split docs │
129
+ │ skip features │
130
+ └─────────────────────────────────────────────────────────┘
131
+
132
+ ┌─────────────────────────────────────────────────────────┐
133
+ │ /vdoc-update or /vdoc-audit │
134
+ │ │
135
+ │ Git Diff ──→ Detect Stale ──→ Report ──→ You Approve │
136
+ │ Detect Gaps (auto) ──→ Patch │
137
+ │ Detect Dead │
138
+ └─────────────────────────────────────────────────────────┘
139
+
140
+ ┌─────────────────────────────────────────────────────────┐
141
+ │ /vdoc-create <feature> │
142
+ │ │
143
+ │ Locate Source ──→ Generate Doc ──→ Update Manifest │
144
+ │ (auto) (auto) (auto) │
145
+ └─────────────────────────────────────────────────────────┘
146
+ ```
147
+
148
+ ---
149
+
100
150
  ## Documentation Template
101
151
 
102
152
  Every generated doc follows a consistent structure:
@@ -171,4 +221,4 @@ None. Your AI coding agent is the runtime.
171
221
 
172
222
  ---
173
223
 
174
- *vdoc v3.5.0 — Documentation skills for AI coding agents*
224
+ *vdoc v3.5.2 — Documentation skills for AI coding agents*
package/bin/vdoc.mjs CHANGED
@@ -232,6 +232,13 @@ function install(platform) {
232
232
 
233
233
  console.log(`\nvdoc → installing for ${platform}\n`);
234
234
 
235
+ // Create vdocs/ output directory
236
+ const vdocsDir = join(CWD, 'vdocs');
237
+ if (!existsSync(vdocsDir)) {
238
+ mkdirSync(vdocsDir, { recursive: true });
239
+ console.log(` ✓ vdocs/`);
240
+ }
241
+
235
242
  for (const file of config.files) {
236
243
  if (file.inject) {
237
244
  injectFile(file.src, file.dest);
@@ -265,6 +272,7 @@ function uninstall() {
265
272
  join(CWD, '.claude', 'skills', 'vdoc-update'),
266
273
  join(CWD, '.claude', 'skills', 'vdoc-create'),
267
274
  join(CWD, '.claude', 'skills', 'vdoc-audit'),
275
+ join(CWD, '.claude', 'skills', 'vdoc'),
268
276
  join(CWD, '.cursor', 'rules', 'vdoc'),
269
277
  join(CWD, '.windsurf', 'skills', 'vdoc'),
270
278
  join(CWD, '.github', 'skills', 'vdoc'),
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@sandrinio/vdoc",
3
- "version": "3.5.2",
3
+ "version": "3.6.0",
4
4
  "description": "Documentation skills for AI coding agents",
5
5
  "type": "module",
6
6
  "bin": {
@@ -51,7 +51,9 @@ This log is your working memory. It feeds directly into Step 2 (Plan).
51
51
 
52
52
  ## Step 2 — Plan
53
53
 
54
- Create `vdocs/_DOCUMENTATION_PLAN.md` listing each proposed doc:
54
+ Write `vdocs/_DOCUMENTATION_PLAN.md` to disk AND present it to the user in the same step. The file must be persisted — do not just show it in chat.
55
+
56
+ Use this format:
55
57
 
56
58
  ```markdown
57
59
  # Documentation Plan
@@ -68,7 +70,7 @@ Create `vdocs/_DOCUMENTATION_PLAN.md` listing each proposed doc:
68
70
  - Docs should be useful for onboarding AND as AI context for planning changes
69
71
  ```
70
72
 
71
- Present the plan to the user. Actively suggest changes:
73
+ After writing the file, present the plan to the user. Actively suggest changes:
72
74
  - "Should I merge X and Y into one doc?"
73
75
  - "I found a websocket system — want that documented separately?"
74
76
  - "Any internal/legacy systems I should skip?"
@@ -77,11 +79,15 @@ Wait for user approval before proceeding.
77
79
 
78
80
  ## Step 3 — Generate
79
81
 
80
- For each approved doc:
82
+ Read the template from `.agents/vdoc/doc-template.md` once before starting.
83
+
84
+ Then generate docs **one at a time, sequentially**. For each approved doc:
81
85
 
82
86
  1. Read ALL relevant source files for that feature — not just the main file, but helpers, types, middleware, tests
83
- 2. Follow the template in `.agents/vdoc/doc-template.md` exactly
84
- 3. Write to `vdocs/FEATURE_NAME_DOC.md`
87
+ 2. Write `vdocs/FEATURE_NAME_DOC.md` following the template exactly
88
+ 3. Confirm the file was written before moving to the next doc
89
+
90
+ Do NOT attempt to generate multiple docs from memory. Each doc is a fresh cycle: read sources → write doc → next.
85
91
 
86
92
  **Writing rules:**
87
93
 
@@ -58,7 +58,9 @@ This log is your working memory. It feeds directly into Step 2 (Plan).
58
58
 
59
59
  ## Step 2 — Plan
60
60
 
61
- Create `.claude/skills/vdoc-config/_DOCUMENTATION_PLAN.md` listing each proposed doc:
61
+ Write `.claude/skills/vdoc-config/_DOCUMENTATION_PLAN.md` to disk AND present it to the user in the same step. The file must be persisted — do not just show it in chat.
62
+
63
+ Use this format:
62
64
 
63
65
  ```markdown
64
66
  # Documentation Plan
@@ -75,7 +77,7 @@ Create `.claude/skills/vdoc-config/_DOCUMENTATION_PLAN.md` listing each proposed
75
77
  - Docs should be useful for onboarding AND as AI context for planning changes
76
78
  ```
77
79
 
78
- Present the plan to the user. Actively suggest changes:
80
+ After writing the file, present the plan to the user. Actively suggest changes:
79
81
  - "Should I merge X and Y into one doc?"
80
82
  - "I found a websocket system — want that documented separately?"
81
83
  - "Any internal/legacy systems I should skip?"
@@ -84,11 +86,15 @@ Present the plan to the user. Actively suggest changes:
84
86
 
85
87
  ## Step 3 — Generate
86
88
 
87
- For each approved doc:
89
+ Read the template from `.claude/skills/vdoc-config/references/doc-template.md` once before starting.
90
+
91
+ Then generate docs **one at a time, sequentially**. For each approved doc:
88
92
 
89
93
  1. Read ALL relevant source files for that feature — not just the main file, but helpers, types, middleware, tests
90
- 2. Read the template from `.claude/skills/vdoc-config/references/doc-template.md` and follow it exactly
91
- 3. Write to `vdocs/FEATURE_NAME_DOC.md`
94
+ 2. Write `vdocs/FEATURE_NAME_DOC.md` following the template exactly
95
+ 3. Confirm the file was written before moving to the next doc
96
+
97
+ Do NOT attempt to generate multiple docs from memory. Each doc is a fresh cycle: read sources → write doc → next.
92
98
 
93
99
  ### Writing Rules
94
100
 
@@ -51,7 +51,9 @@ This log is your working memory. It feeds directly into Step 2 (Plan).
51
51
 
52
52
  ## Step 2 — Plan
53
53
 
54
- Create `vdocs/_DOCUMENTATION_PLAN.md` listing each proposed doc:
54
+ Write `vdocs/_DOCUMENTATION_PLAN.md` to disk AND present it to the user in the same step. The file must be persisted — do not just show it in chat.
55
+
56
+ Use this format:
55
57
 
56
58
  ```markdown
57
59
  # Documentation Plan
@@ -68,7 +70,7 @@ Create `vdocs/_DOCUMENTATION_PLAN.md` listing each proposed doc:
68
70
  - Docs should be useful for onboarding AND as AI context for planning changes
69
71
  ```
70
72
 
71
- Present the plan to the user. Actively suggest changes:
73
+ After writing the file, present the plan to the user. Actively suggest changes:
72
74
  - "Should I merge X and Y into one doc?"
73
75
  - "I found a websocket system — want that documented separately?"
74
76
  - "Any internal/legacy systems I should skip?"
@@ -77,11 +79,15 @@ Wait for user approval before proceeding.
77
79
 
78
80
  ## Step 3 — Generate
79
81
 
80
- For each approved doc:
82
+ Read the template from `references/doc-template.md` once before starting.
83
+
84
+ Then generate docs **one at a time, sequentially**. For each approved doc:
81
85
 
82
86
  1. Read ALL relevant source files for that feature — not just the main file, but helpers, types, middleware, tests
83
- 2. Follow the template in `references/doc-template.md` exactly
84
- 3. Write to `vdocs/FEATURE_NAME_DOC.md`
87
+ 2. Write `vdocs/FEATURE_NAME_DOC.md` following the template exactly
88
+ 3. Confirm the file was written before moving to the next doc
89
+
90
+ Do NOT attempt to generate multiple docs from memory. Each doc is a fresh cycle: read sources → write doc → next.
85
91
 
86
92
  **Writing rules:**
87
93
 
@@ -51,7 +51,9 @@ This log is your working memory. It feeds directly into Step 2 (Plan).
51
51
 
52
52
  ## Step 2 — Plan
53
53
 
54
- Create `vdocs/_DOCUMENTATION_PLAN.md` listing each proposed doc:
54
+ Write `vdocs/_DOCUMENTATION_PLAN.md` to disk AND present it to the user in the same step. The file must be persisted — do not just show it in chat.
55
+
56
+ Use this format:
55
57
 
56
58
  ```markdown
57
59
  # Documentation Plan
@@ -68,7 +70,7 @@ Create `vdocs/_DOCUMENTATION_PLAN.md` listing each proposed doc:
68
70
  - Docs should be useful for onboarding AND as AI context for planning changes
69
71
  ```
70
72
 
71
- Present the plan to the user. Actively suggest changes:
73
+ After writing the file, present the plan to the user. Actively suggest changes:
72
74
  - "Should I merge X and Y into one doc?"
73
75
  - "I found a websocket system — want that documented separately?"
74
76
  - "Any internal/legacy systems I should skip?"
@@ -77,11 +79,15 @@ Wait for user approval before proceeding.
77
79
 
78
80
  ## Step 3 — Generate
79
81
 
80
- For each approved doc:
82
+ Read the template from `references/doc-template.md` once before starting.
83
+
84
+ Then generate docs **one at a time, sequentially**. For each approved doc:
81
85
 
82
86
  1. Read ALL relevant source files for that feature — not just the main file, but helpers, types, middleware, tests
83
- 2. Follow the template in `references/doc-template.md` exactly
84
- 3. Write to `vdocs/FEATURE_NAME_DOC.md`
87
+ 2. Write `vdocs/FEATURE_NAME_DOC.md` following the template exactly
88
+ 3. Confirm the file was written before moving to the next doc
89
+
90
+ Do NOT attempt to generate multiple docs from memory. Each doc is a fresh cycle: read sources → write doc → next.
85
91
 
86
92
  **Writing rules:**
87
93
 
@@ -51,7 +51,9 @@ This log is your working memory. It feeds directly into Step 2 (Plan).
51
51
 
52
52
  ## Step 2 — Plan
53
53
 
54
- Create `vdocs/_DOCUMENTATION_PLAN.md` listing each proposed doc:
54
+ Write `vdocs/_DOCUMENTATION_PLAN.md` to disk AND present it to the user in the same step. The file must be persisted — do not just show it in chat.
55
+
56
+ Use this format:
55
57
 
56
58
  ```markdown
57
59
  # Documentation Plan
@@ -68,7 +70,7 @@ Create `vdocs/_DOCUMENTATION_PLAN.md` listing each proposed doc:
68
70
  - Docs should be useful for onboarding AND as AI context for planning changes
69
71
  ```
70
72
 
71
- Present the plan to the user. Actively suggest changes:
73
+ After writing the file, present the plan to the user. Actively suggest changes:
72
74
  - "Should I merge X and Y into one doc?"
73
75
  - "I found a websocket system — want that documented separately?"
74
76
  - "Any internal/legacy systems I should skip?"
@@ -77,11 +79,15 @@ Wait for user approval before proceeding.
77
79
 
78
80
  ## Step 3 — Generate
79
81
 
80
- For each approved doc:
82
+ Read the template from `references/doc-template.md` once before starting.
83
+
84
+ Then generate docs **one at a time, sequentially**. For each approved doc:
81
85
 
82
86
  1. Read ALL relevant source files for that feature — not just the main file, but helpers, types, middleware, tests
83
- 2. Follow the template in `references/doc-template.md` exactly
84
- 3. Write to `vdocs/FEATURE_NAME_DOC.md`
87
+ 2. Write `vdocs/FEATURE_NAME_DOC.md` following the template exactly
88
+ 3. Confirm the file was written before moving to the next doc
89
+
90
+ Do NOT attempt to generate multiple docs from memory. Each doc is a fresh cycle: read sources → write doc → next.
85
91
 
86
92
  **Writing rules:**
87
93
 
@@ -51,7 +51,9 @@ This log is your working memory. It feeds directly into Step 2 (Plan).
51
51
 
52
52
  ## Step 2 — Plan
53
53
 
54
- Create `vdocs/_DOCUMENTATION_PLAN.md` listing each proposed doc:
54
+ Write `vdocs/_DOCUMENTATION_PLAN.md` to disk AND present it to the user in the same step. The file must be persisted — do not just show it in chat.
55
+
56
+ Use this format:
55
57
 
56
58
  ```markdown
57
59
  # Documentation Plan
@@ -68,7 +70,7 @@ Create `vdocs/_DOCUMENTATION_PLAN.md` listing each proposed doc:
68
70
  - Docs should be useful for onboarding AND as AI context for planning changes
69
71
  ```
70
72
 
71
- Present the plan to the user. Actively suggest changes:
73
+ After writing the file, present the plan to the user. Actively suggest changes:
72
74
  - "Should I merge X and Y into one doc?"
73
75
  - "I found a websocket system — want that documented separately?"
74
76
  - "Any internal/legacy systems I should skip?"
@@ -77,11 +79,15 @@ Wait for user approval before proceeding.
77
79
 
78
80
  ## Step 3 — Generate
79
81
 
80
- For each approved doc:
82
+ Read the template from `.gemini/vdoc/doc-template.md` once before starting.
83
+
84
+ Then generate docs **one at a time, sequentially**. For each approved doc:
81
85
 
82
86
  1. Read ALL relevant source files for that feature — not just the main file, but helpers, types, middleware, tests
83
- 2. Follow the template in `.gemini/vdoc/doc-template.md` exactly
84
- 3. Write to `vdocs/FEATURE_NAME_DOC.md`
87
+ 2. Write `vdocs/FEATURE_NAME_DOC.md` following the template exactly
88
+ 3. Confirm the file was written before moving to the next doc
89
+
90
+ Do NOT attempt to generate multiple docs from memory. Each doc is a fresh cycle: read sources → write doc → next.
85
91
 
86
92
  **Writing rules:**
87
93
 
@@ -10,8 +10,8 @@ Run documentation workflows for this project. Full instructions are in GEMINI.md
10
10
  ## If "init" or no vdocs/ folder exists:
11
11
 
12
12
  1. **Explore** — Read the codebase: tech stack, features, architecture, integrations, entry points. Read actual files.
13
- 2. **Plan** — Create `vdocs/_DOCUMENTATION_PLAN.md` listing proposed docs. Present to user. Wait for approval.
14
- 3. **Generate** — For each doc, read ALL relevant source files. Write `vdocs/FEATURE_NAME_DOC.md` following the template at @.gemini/vdoc/doc-template.md
13
+ 2. **Plan** — Write `vdocs/_DOCUMENTATION_PLAN.md` to disk listing proposed docs. Present to user. Wait for approval.
14
+ 3. **Generate** — Read template from @.gemini/vdoc/doc-template.md once. Then generate docs **one at a time**: read sources → write `vdocs/FEATURE_NAME_DOC.md` confirm next
15
15
  4. **Manifest** — Create `vdocs/_manifest.json` using schema at @.gemini/vdoc/manifest-schema.json
16
16
  5. **Verify** — Every doc has mermaid diagrams, real paths, 2+ constraints, cross-references.
17
17
 
@@ -51,7 +51,9 @@ This log is your working memory. It feeds directly into Step 2 (Plan).
51
51
 
52
52
  ## Step 2 — Plan
53
53
 
54
- Create `vdocs/_DOCUMENTATION_PLAN.md` listing each proposed doc:
54
+ Write `vdocs/_DOCUMENTATION_PLAN.md` to disk AND present it to the user in the same step. The file must be persisted — do not just show it in chat.
55
+
56
+ Use this format:
55
57
 
56
58
  ```markdown
57
59
  # Documentation Plan
@@ -68,7 +70,7 @@ Create `vdocs/_DOCUMENTATION_PLAN.md` listing each proposed doc:
68
70
  - Docs should be useful for onboarding AND as AI context for planning changes
69
71
  ```
70
72
 
71
- Present the plan to the user. Actively suggest changes:
73
+ After writing the file, present the plan to the user. Actively suggest changes:
72
74
  - "Should I merge X and Y into one doc?"
73
75
  - "I found a websocket system — want that documented separately?"
74
76
  - "Any internal/legacy systems I should skip?"
@@ -77,11 +79,15 @@ Wait for user approval before proceeding.
77
79
 
78
80
  ## Step 3 — Generate
79
81
 
80
- For each approved doc:
82
+ Read the template from `.aiassistant/vdoc/doc-template.md` once before starting.
83
+
84
+ Then generate docs **one at a time, sequentially**. For each approved doc:
81
85
 
82
86
  1. Read ALL relevant source files for that feature — not just the main file, but helpers, types, middleware, tests
83
- 2. Follow the template in `.aiassistant/vdoc/doc-template.md` exactly
84
- 3. Write to `vdocs/FEATURE_NAME_DOC.md`
87
+ 2. Write `vdocs/FEATURE_NAME_DOC.md` following the template exactly
88
+ 3. Confirm the file was written before moving to the next doc
89
+
90
+ Do NOT attempt to generate multiple docs from memory. Each doc is a fresh cycle: read sources → write doc → next.
85
91
 
86
92
  **Writing rules:**
87
93
 
@@ -51,7 +51,9 @@ This log is your working memory. It feeds directly into Step 2 (Plan).
51
51
 
52
52
  ## Step 2 — Plan
53
53
 
54
- Create `vdocs/_DOCUMENTATION_PLAN.md` listing each proposed doc:
54
+ Write `vdocs/_DOCUMENTATION_PLAN.md` to disk AND present it to the user in the same step. The file must be persisted — do not just show it in chat.
55
+
56
+ Use this format:
55
57
 
56
58
  ```markdown
57
59
  # Documentation Plan
@@ -68,7 +70,7 @@ Create `vdocs/_DOCUMENTATION_PLAN.md` listing each proposed doc:
68
70
  - Docs should be useful for onboarding AND as AI context for planning changes
69
71
  ```
70
72
 
71
- Present the plan to the user. Actively suggest changes:
73
+ After writing the file, present the plan to the user. Actively suggest changes:
72
74
  - "Should I merge X and Y into one doc?"
73
75
  - "I found a websocket system — want that documented separately?"
74
76
  - "Any internal/legacy systems I should skip?"
@@ -77,11 +79,15 @@ Wait for user approval before proceeding.
77
79
 
78
80
  ## Step 3 — Generate
79
81
 
80
- For each approved doc:
82
+ Read the template from `.junie/vdoc/doc-template.md` once before starting.
83
+
84
+ Then generate docs **one at a time, sequentially**. For each approved doc:
81
85
 
82
86
  1. Read ALL relevant source files for that feature — not just the main file, but helpers, types, middleware, tests
83
- 2. Follow the template in `.junie/vdoc/doc-template.md` exactly
84
- 3. Write to `vdocs/FEATURE_NAME_DOC.md`
87
+ 2. Write `vdocs/FEATURE_NAME_DOC.md` following the template exactly
88
+ 3. Confirm the file was written before moving to the next doc
89
+
90
+ Do NOT attempt to generate multiple docs from memory. Each doc is a fresh cycle: read sources → write doc → next.
85
91
 
86
92
  **Writing rules:**
87
93
 
@@ -51,7 +51,9 @@ This log is your working memory. It feeds directly into Step 2 (Plan).
51
51
 
52
52
  ## Step 2 — Plan
53
53
 
54
- Create `vdocs/_DOCUMENTATION_PLAN.md` listing each proposed doc:
54
+ Write `vdocs/_DOCUMENTATION_PLAN.md` to disk AND present it to the user in the same step. The file must be persisted — do not just show it in chat.
55
+
56
+ Use this format:
55
57
 
56
58
  ```markdown
57
59
  # Documentation Plan
@@ -68,7 +70,7 @@ Create `vdocs/_DOCUMENTATION_PLAN.md` listing each proposed doc:
68
70
  - Docs should be useful for onboarding AND as AI context for planning changes
69
71
  ```
70
72
 
71
- Present the plan to the user. Actively suggest changes:
73
+ After writing the file, present the plan to the user. Actively suggest changes:
72
74
  - "Should I merge X and Y into one doc?"
73
75
  - "I found a websocket system — want that documented separately?"
74
76
  - "Any internal/legacy systems I should skip?"
@@ -77,11 +79,15 @@ Wait for user approval before proceeding.
77
79
 
78
80
  ## Step 3 — Generate
79
81
 
80
- For each approved doc:
82
+ Read the template from [doc-template.md](./doc-template.md) once before starting.
83
+
84
+ Then generate docs **one at a time, sequentially**. For each approved doc:
81
85
 
82
86
  1. Read ALL relevant source files for that feature — not just the main file, but helpers, types, middleware, tests
83
- 2. Follow the template in [doc-template.md](./doc-template.md) exactly
84
- 3. Write to `vdocs/FEATURE_NAME_DOC.md`
87
+ 2. Write `vdocs/FEATURE_NAME_DOC.md` following the template exactly
88
+ 3. Confirm the file was written before moving to the next doc
89
+
90
+ Do NOT attempt to generate multiple docs from memory. Each doc is a fresh cycle: read sources → write doc → next.
85
91
 
86
92
  **Writing rules:**
87
93
 
@@ -51,7 +51,9 @@ This log is your working memory. It feeds directly into Step 2 (Plan).
51
51
 
52
52
  ## Step 2 — Plan
53
53
 
54
- Create `vdocs/_DOCUMENTATION_PLAN.md` listing each proposed doc:
54
+ Write `vdocs/_DOCUMENTATION_PLAN.md` to disk AND present it to the user in the same step. The file must be persisted — do not just show it in chat.
55
+
56
+ Use this format:
55
57
 
56
58
  ```markdown
57
59
  # Documentation Plan
@@ -68,7 +70,7 @@ Create `vdocs/_DOCUMENTATION_PLAN.md` listing each proposed doc:
68
70
  - Docs should be useful for onboarding AND as AI context for planning changes
69
71
  ```
70
72
 
71
- Present the plan to the user. Actively suggest changes:
73
+ After writing the file, present the plan to the user. Actively suggest changes:
72
74
  - "Should I merge X and Y into one doc?"
73
75
  - "I found a websocket system — want that documented separately?"
74
76
  - "Any internal/legacy systems I should skip?"
@@ -77,11 +79,15 @@ Wait for user approval before proceeding.
77
79
 
78
80
  ## Step 3 — Generate
79
81
 
80
- For each approved doc:
82
+ Read the template from `resources/doc-template.md` once before starting.
83
+
84
+ Then generate docs **one at a time, sequentially**. For each approved doc:
81
85
 
82
86
  1. Read ALL relevant source files for that feature — not just the main file, but helpers, types, middleware, tests
83
- 2. Follow the template in `resources/doc-template.md` exactly
84
- 3. Write to `vdocs/FEATURE_NAME_DOC.md`
87
+ 2. Write `vdocs/FEATURE_NAME_DOC.md` following the template exactly
88
+ 3. Confirm the file was written before moving to the next doc
89
+
90
+ Do NOT attempt to generate multiple docs from memory. Each doc is a fresh cycle: read sources → write doc → next.
85
91
 
86
92
  **Writing rules:**
87
93