@sandrinio/vdoc 3.7.0 → 3.7.1
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 +1 -1
- package/skills/agents/references/init-workflow.md +4 -3
- package/skills/claude/references/create-workflow.md +1 -0
- package/skills/claude/references/init-workflow.md +4 -3
- package/skills/cline/references/init-workflow.md +4 -3
- package/skills/continue/references/init-workflow.md +4 -3
- package/skills/cursor/references/init-workflow.md +4 -3
- package/skills/gemini/references/init-workflow.md +4 -3
- package/skills/jetbrains-ai/references/init-workflow.md +4 -3
- package/skills/junie/references/init-workflow.md +4 -3
- package/skills/vscode/references/init-workflow.md +4 -3
- package/skills/windsurf/resources/init-workflow.md +4 -3
package/package.json
CHANGED
|
@@ -85,10 +85,11 @@ Then generate docs **one at a time, sequentially**. For each approved doc:
|
|
|
85
85
|
|
|
86
86
|
1. Read ALL relevant source files for that feature — not just the main file, but helpers, types, middleware, tests
|
|
87
87
|
2. **Trace the end-to-end flow** — pick the primary user action and follow it through every layer: frontend → API route → service/lib → database → external service → response. Read each file in the chain. Don't stop at the service layer.
|
|
88
|
-
3.
|
|
89
|
-
4.
|
|
88
|
+
3. **Search for consumers** — grep for the feature's key types, table names, API endpoints, and module imports across the entire codebase. This catches secondary workflows (exports, scheduled jobs, webhooks, notifications, external automation) that live in different directories but depend on this feature. If you find consumers, read them and include those workflows in the doc.
|
|
89
|
+
4. Write `vdocs/FEATURE_NAME_DOC.md` following the template exactly
|
|
90
|
+
5. Confirm the file was written before moving to the next doc
|
|
90
91
|
|
|
91
|
-
Do NOT attempt to generate multiple docs from memory. Each doc is a fresh cycle: read sources → trace flows → write doc → next.
|
|
92
|
+
Do NOT attempt to generate multiple docs from memory. Each doc is a fresh cycle: read sources → trace flows → search consumers → write doc → next.
|
|
92
93
|
|
|
93
94
|
**Writing rules:**
|
|
94
95
|
|
|
@@ -10,6 +10,7 @@ Use the user's description to find the relevant source files:
|
|
|
10
10
|
2. Otherwise, search the codebase with Glob and Grep to find files matching the user's description
|
|
11
11
|
3. Read ALL relevant source files — not just the main file, but helpers, types, middleware, tests, API routes, components
|
|
12
12
|
4. **Trace the end-to-end flow** — pick the primary user action and follow it through every layer: frontend → API route → service/lib → database → external service → response. Read each file in the chain. Don't stop at the service layer.
|
|
13
|
+
5. **Search for consumers** — grep for the feature's key types, table names, API endpoints, and module imports across the entire codebase. This catches secondary workflows (exports, scheduled jobs, webhooks, notifications, external automation) that live in different directories but depend on this feature. If you find consumers, read them and include those workflows in the doc.
|
|
13
14
|
|
|
14
15
|
Do not skim. Understand how the feature actually works before writing.
|
|
15
16
|
|
|
@@ -85,10 +85,11 @@ Then generate docs **one at a time, sequentially**. For each approved doc:
|
|
|
85
85
|
|
|
86
86
|
1. Read ALL relevant source files for that feature — not just the main file, but helpers, types, middleware, tests
|
|
87
87
|
2. **Trace the end-to-end flow** — pick the primary user action and follow it through every layer: frontend → API route → service/lib → database → external service → response. Read each file in the chain. Don't stop at the service layer.
|
|
88
|
-
3.
|
|
89
|
-
4.
|
|
88
|
+
3. **Search for consumers** — grep for the feature's key types, table names, API endpoints, and module imports across the entire codebase. This catches secondary workflows (exports, scheduled jobs, webhooks, notifications, external automation) that live in different directories but depend on this feature. If you find consumers, read them and include those workflows in the doc.
|
|
89
|
+
4. Write `vdocs/FEATURE_NAME_DOC.md` following the template exactly
|
|
90
|
+
5. Confirm the file was written before moving to the next doc
|
|
90
91
|
|
|
91
|
-
Do NOT attempt to generate multiple docs from memory. Each doc is a fresh cycle: read sources → trace flows → write doc → next.
|
|
92
|
+
Do NOT attempt to generate multiple docs from memory. Each doc is a fresh cycle: read sources → trace flows → search consumers → write doc → next.
|
|
92
93
|
|
|
93
94
|
**Writing rules:**
|
|
94
95
|
|
|
@@ -85,10 +85,11 @@ Then generate docs **one at a time, sequentially**. For each approved doc:
|
|
|
85
85
|
|
|
86
86
|
1. Read ALL relevant source files for that feature — not just the main file, but helpers, types, middleware, tests
|
|
87
87
|
2. **Trace the end-to-end flow** — pick the primary user action and follow it through every layer: frontend → API route → service/lib → database → external service → response. Read each file in the chain. Don't stop at the service layer.
|
|
88
|
-
3.
|
|
89
|
-
4.
|
|
88
|
+
3. **Search for consumers** — grep for the feature's key types, table names, API endpoints, and module imports across the entire codebase. This catches secondary workflows (exports, scheduled jobs, webhooks, notifications, external automation) that live in different directories but depend on this feature. If you find consumers, read them and include those workflows in the doc.
|
|
89
|
+
4. Write `vdocs/FEATURE_NAME_DOC.md` following the template exactly
|
|
90
|
+
5. Confirm the file was written before moving to the next doc
|
|
90
91
|
|
|
91
|
-
Do NOT attempt to generate multiple docs from memory. Each doc is a fresh cycle: read sources → trace flows → write doc → next.
|
|
92
|
+
Do NOT attempt to generate multiple docs from memory. Each doc is a fresh cycle: read sources → trace flows → search consumers → write doc → next.
|
|
92
93
|
|
|
93
94
|
**Writing rules:**
|
|
94
95
|
|
|
@@ -85,10 +85,11 @@ Then generate docs **one at a time, sequentially**. For each approved doc:
|
|
|
85
85
|
|
|
86
86
|
1. Read ALL relevant source files for that feature — not just the main file, but helpers, types, middleware, tests
|
|
87
87
|
2. **Trace the end-to-end flow** — pick the primary user action and follow it through every layer: frontend → API route → service/lib → database → external service → response. Read each file in the chain. Don't stop at the service layer.
|
|
88
|
-
3.
|
|
89
|
-
4.
|
|
88
|
+
3. **Search for consumers** — grep for the feature's key types, table names, API endpoints, and module imports across the entire codebase. This catches secondary workflows (exports, scheduled jobs, webhooks, notifications, external automation) that live in different directories but depend on this feature. If you find consumers, read them and include those workflows in the doc.
|
|
89
|
+
4. Write `vdocs/FEATURE_NAME_DOC.md` following the template exactly
|
|
90
|
+
5. Confirm the file was written before moving to the next doc
|
|
90
91
|
|
|
91
|
-
Do NOT attempt to generate multiple docs from memory. Each doc is a fresh cycle: read sources → trace flows → write doc → next.
|
|
92
|
+
Do NOT attempt to generate multiple docs from memory. Each doc is a fresh cycle: read sources → trace flows → search consumers → write doc → next.
|
|
92
93
|
|
|
93
94
|
**Writing rules:**
|
|
94
95
|
|
|
@@ -85,10 +85,11 @@ Then generate docs **one at a time, sequentially**. For each approved doc:
|
|
|
85
85
|
|
|
86
86
|
1. Read ALL relevant source files for that feature — not just the main file, but helpers, types, middleware, tests
|
|
87
87
|
2. **Trace the end-to-end flow** — pick the primary user action and follow it through every layer: frontend → API route → service/lib → database → external service → response. Read each file in the chain. Don't stop at the service layer.
|
|
88
|
-
3.
|
|
89
|
-
4.
|
|
88
|
+
3. **Search for consumers** — grep for the feature's key types, table names, API endpoints, and module imports across the entire codebase. This catches secondary workflows (exports, scheduled jobs, webhooks, notifications, external automation) that live in different directories but depend on this feature. If you find consumers, read them and include those workflows in the doc.
|
|
89
|
+
4. Write `vdocs/FEATURE_NAME_DOC.md` following the template exactly
|
|
90
|
+
5. Confirm the file was written before moving to the next doc
|
|
90
91
|
|
|
91
|
-
Do NOT attempt to generate multiple docs from memory. Each doc is a fresh cycle: read sources → trace flows → write doc → next.
|
|
92
|
+
Do NOT attempt to generate multiple docs from memory. Each doc is a fresh cycle: read sources → trace flows → search consumers → write doc → next.
|
|
92
93
|
|
|
93
94
|
**Writing rules:**
|
|
94
95
|
|
|
@@ -85,10 +85,11 @@ Then generate docs **one at a time, sequentially**. For each approved doc:
|
|
|
85
85
|
|
|
86
86
|
1. Read ALL relevant source files for that feature — not just the main file, but helpers, types, middleware, tests
|
|
87
87
|
2. **Trace the end-to-end flow** — pick the primary user action and follow it through every layer: frontend → API route → service/lib → database → external service → response. Read each file in the chain. Don't stop at the service layer.
|
|
88
|
-
3.
|
|
89
|
-
4.
|
|
88
|
+
3. **Search for consumers** — grep for the feature's key types, table names, API endpoints, and module imports across the entire codebase. This catches secondary workflows (exports, scheduled jobs, webhooks, notifications, external automation) that live in different directories but depend on this feature. If you find consumers, read them and include those workflows in the doc.
|
|
89
|
+
4. Write `vdocs/FEATURE_NAME_DOC.md` following the template exactly
|
|
90
|
+
5. Confirm the file was written before moving to the next doc
|
|
90
91
|
|
|
91
|
-
Do NOT attempt to generate multiple docs from memory. Each doc is a fresh cycle: read sources → trace flows → write doc → next.
|
|
92
|
+
Do NOT attempt to generate multiple docs from memory. Each doc is a fresh cycle: read sources → trace flows → search consumers → write doc → next.
|
|
92
93
|
|
|
93
94
|
**Writing rules:**
|
|
94
95
|
|
|
@@ -85,10 +85,11 @@ Then generate docs **one at a time, sequentially**. For each approved doc:
|
|
|
85
85
|
|
|
86
86
|
1. Read ALL relevant source files for that feature — not just the main file, but helpers, types, middleware, tests
|
|
87
87
|
2. **Trace the end-to-end flow** — pick the primary user action and follow it through every layer: frontend → API route → service/lib → database → external service → response. Read each file in the chain. Don't stop at the service layer.
|
|
88
|
-
3.
|
|
89
|
-
4.
|
|
88
|
+
3. **Search for consumers** — grep for the feature's key types, table names, API endpoints, and module imports across the entire codebase. This catches secondary workflows (exports, scheduled jobs, webhooks, notifications, external automation) that live in different directories but depend on this feature. If you find consumers, read them and include those workflows in the doc.
|
|
89
|
+
4. Write `vdocs/FEATURE_NAME_DOC.md` following the template exactly
|
|
90
|
+
5. Confirm the file was written before moving to the next doc
|
|
90
91
|
|
|
91
|
-
Do NOT attempt to generate multiple docs from memory. Each doc is a fresh cycle: read sources → trace flows → write doc → next.
|
|
92
|
+
Do NOT attempt to generate multiple docs from memory. Each doc is a fresh cycle: read sources → trace flows → search consumers → write doc → next.
|
|
92
93
|
|
|
93
94
|
**Writing rules:**
|
|
94
95
|
|
|
@@ -85,10 +85,11 @@ Then generate docs **one at a time, sequentially**. For each approved doc:
|
|
|
85
85
|
|
|
86
86
|
1. Read ALL relevant source files for that feature — not just the main file, but helpers, types, middleware, tests
|
|
87
87
|
2. **Trace the end-to-end flow** — pick the primary user action and follow it through every layer: frontend → API route → service/lib → database → external service → response. Read each file in the chain. Don't stop at the service layer.
|
|
88
|
-
3.
|
|
89
|
-
4.
|
|
88
|
+
3. **Search for consumers** — grep for the feature's key types, table names, API endpoints, and module imports across the entire codebase. This catches secondary workflows (exports, scheduled jobs, webhooks, notifications, external automation) that live in different directories but depend on this feature. If you find consumers, read them and include those workflows in the doc.
|
|
89
|
+
4. Write `vdocs/FEATURE_NAME_DOC.md` following the template exactly
|
|
90
|
+
5. Confirm the file was written before moving to the next doc
|
|
90
91
|
|
|
91
|
-
Do NOT attempt to generate multiple docs from memory. Each doc is a fresh cycle: read sources → trace flows → write doc → next.
|
|
92
|
+
Do NOT attempt to generate multiple docs from memory. Each doc is a fresh cycle: read sources → trace flows → search consumers → write doc → next.
|
|
92
93
|
|
|
93
94
|
**Writing rules:**
|
|
94
95
|
|
|
@@ -85,10 +85,11 @@ Then generate docs **one at a time, sequentially**. For each approved doc:
|
|
|
85
85
|
|
|
86
86
|
1. Read ALL relevant source files for that feature — not just the main file, but helpers, types, middleware, tests
|
|
87
87
|
2. **Trace the end-to-end flow** — pick the primary user action and follow it through every layer: frontend → API route → service/lib → database → external service → response. Read each file in the chain. Don't stop at the service layer.
|
|
88
|
-
3.
|
|
89
|
-
4.
|
|
88
|
+
3. **Search for consumers** — grep for the feature's key types, table names, API endpoints, and module imports across the entire codebase. This catches secondary workflows (exports, scheduled jobs, webhooks, notifications, external automation) that live in different directories but depend on this feature. If you find consumers, read them and include those workflows in the doc.
|
|
89
|
+
4. Write `vdocs/FEATURE_NAME_DOC.md` following the template exactly
|
|
90
|
+
5. Confirm the file was written before moving to the next doc
|
|
90
91
|
|
|
91
|
-
Do NOT attempt to generate multiple docs from memory. Each doc is a fresh cycle: read sources → trace flows → write doc → next.
|
|
92
|
+
Do NOT attempt to generate multiple docs from memory. Each doc is a fresh cycle: read sources → trace flows → search consumers → write doc → next.
|
|
92
93
|
|
|
93
94
|
**Writing rules:**
|
|
94
95
|
|
|
@@ -85,10 +85,11 @@ Then generate docs **one at a time, sequentially**. For each approved doc:
|
|
|
85
85
|
|
|
86
86
|
1. Read ALL relevant source files for that feature — not just the main file, but helpers, types, middleware, tests
|
|
87
87
|
2. **Trace the end-to-end flow** — pick the primary user action and follow it through every layer: frontend → API route → service/lib → database → external service → response. Read each file in the chain. Don't stop at the service layer.
|
|
88
|
-
3.
|
|
89
|
-
4.
|
|
88
|
+
3. **Search for consumers** — grep for the feature's key types, table names, API endpoints, and module imports across the entire codebase. This catches secondary workflows (exports, scheduled jobs, webhooks, notifications, external automation) that live in different directories but depend on this feature. If you find consumers, read them and include those workflows in the doc.
|
|
89
|
+
4. Write `vdocs/FEATURE_NAME_DOC.md` following the template exactly
|
|
90
|
+
5. Confirm the file was written before moving to the next doc
|
|
90
91
|
|
|
91
|
-
Do NOT attempt to generate multiple docs from memory. Each doc is a fresh cycle: read sources → trace flows → write doc → next.
|
|
92
|
+
Do NOT attempt to generate multiple docs from memory. Each doc is a fresh cycle: read sources → trace flows → search consumers → write doc → next.
|
|
92
93
|
|
|
93
94
|
**Writing rules:**
|
|
94
95
|
|