@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 +62 -12
- package/bin/vdoc.mjs +8 -0
- package/package.json +1 -1
- package/skills/agents/references/init-workflow.md +11 -5
- package/skills/claude/vdoc-init.md +11 -5
- package/skills/cline/references/init-workflow.md +11 -5
- package/skills/continue/references/init-workflow.md +11 -5
- package/skills/cursor/references/init-workflow.md +11 -5
- package/skills/gemini/references/init-workflow.md +11 -5
- package/skills/gemini/vdoc.toml +2 -2
- package/skills/jetbrains-ai/references/init-workflow.md +11 -5
- package/skills/junie/references/init-workflow.md +11 -5
- package/skills/vscode/references/init-workflow.md +11 -5
- package/skills/windsurf/resources/init-workflow.md +11 -5
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
|
|
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
|
-
|
|
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
|
-
|
|
77
|
+
### 3. Update — `/vdoc-update`
|
|
61
78
|
|
|
62
|
-
|
|
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
|
-
|
|
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
|
-
|
|
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
|
|
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.
|
|
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
|
@@ -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
|
-
|
|
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
|
-
|
|
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
|
-
|
|
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.
|
|
84
|
-
3.
|
|
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
|
-
|
|
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
|
-
|
|
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
|
-
|
|
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.
|
|
91
|
-
3.
|
|
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
|
-
|
|
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
|
-
|
|
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
|
-
|
|
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.
|
|
84
|
-
3.
|
|
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
|
-
|
|
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
|
-
|
|
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
|
-
|
|
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.
|
|
84
|
-
3.
|
|
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
|
-
|
|
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
|
-
|
|
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
|
-
|
|
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.
|
|
84
|
-
3.
|
|
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
|
-
|
|
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
|
-
|
|
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
|
-
|
|
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.
|
|
84
|
-
3.
|
|
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
|
|
package/skills/gemini/vdoc.toml
CHANGED
|
@@ -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** —
|
|
14
|
-
3. **Generate** —
|
|
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
|
-
|
|
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
|
-
|
|
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
|
-
|
|
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.
|
|
84
|
-
3.
|
|
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
|
-
|
|
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
|
-
|
|
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
|
-
|
|
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.
|
|
84
|
-
3.
|
|
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
|
-
|
|
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
|
-
|
|
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
|
-
|
|
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.
|
|
84
|
-
3.
|
|
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
|
-
|
|
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
|
-
|
|
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
|
-
|
|
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.
|
|
84
|
-
3.
|
|
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
|
|