@sandrinio/vdoc 3.0.1 → 3.4.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/bin/vdoc.mjs +78 -11
- package/package.json +1 -1
- package/skills/agents/AGENTS.md +17 -143
- package/skills/agents/references/audit-workflow.md +65 -0
- package/skills/agents/references/doc-template.md +67 -0
- package/skills/agents/references/exploration-strategies.md +341 -0
- package/skills/agents/references/init-workflow.md +123 -0
- package/skills/agents/references/manifest-schema.json +16 -0
- package/skills/claude/SKILL.md +14 -41
- package/skills/claude/references/exploration-strategies.md +341 -0
- package/skills/claude/references/init-workflow.md +44 -7
- package/skills/claude/vdoc-audit.md +80 -0
- package/skills/claude/vdoc-init.md +216 -0
- package/skills/cline/references/audit-workflow.md +65 -0
- package/skills/cline/references/doc-template.md +67 -0
- package/skills/cline/references/exploration-strategies.md +341 -0
- package/skills/cline/references/init-workflow.md +123 -0
- package/skills/cline/references/manifest-schema.json +16 -0
- package/skills/cline/vdoc-workflow.md +3 -13
- package/skills/cline/vdoc.md +10 -148
- package/skills/continue/references/audit-workflow.md +65 -0
- package/skills/continue/references/doc-template.md +67 -0
- package/skills/continue/references/exploration-strategies.md +341 -0
- package/skills/continue/references/init-workflow.md +123 -0
- package/skills/continue/references/manifest-schema.json +16 -0
- package/skills/continue/vdoc-command.md +3 -13
- package/skills/continue/vdoc.md +9 -147
- package/skills/cursor/RULE.md +68 -0
- package/skills/cursor/references/audit-workflow.md +65 -0
- package/skills/cursor/references/doc-template.md +67 -0
- package/skills/cursor/references/exploration-strategies.md +341 -0
- package/skills/cursor/references/init-workflow.md +123 -0
- package/skills/cursor/references/manifest-schema.json +16 -0
- package/skills/cursor/vdoc-command.md +3 -13
- package/skills/gemini/GEMINI.md +17 -143
- package/skills/gemini/references/audit-workflow.md +65 -0
- package/skills/gemini/references/doc-template.md +67 -0
- package/skills/gemini/references/exploration-strategies.md +341 -0
- package/skills/gemini/references/init-workflow.md +123 -0
- package/skills/gemini/references/manifest-schema.json +16 -0
- package/skills/gemini/vdoc.toml +3 -9
- package/skills/jetbrains-ai/references/audit-workflow.md +65 -0
- package/skills/jetbrains-ai/references/doc-template.md +67 -0
- package/skills/jetbrains-ai/references/exploration-strategies.md +341 -0
- package/skills/jetbrains-ai/references/init-workflow.md +123 -0
- package/skills/jetbrains-ai/references/manifest-schema.json +16 -0
- package/skills/jetbrains-ai/vdoc.md +17 -143
- package/skills/junie/guidelines.md +17 -143
- package/skills/junie/references/audit-workflow.md +65 -0
- package/skills/junie/references/doc-template.md +67 -0
- package/skills/junie/references/exploration-strategies.md +341 -0
- package/skills/junie/references/init-workflow.md +123 -0
- package/skills/junie/references/manifest-schema.json +16 -0
- package/skills/vscode/SKILL.md +39 -0
- package/skills/vscode/references/audit-workflow.md +65 -0
- package/skills/vscode/references/doc-template.md +67 -0
- package/skills/vscode/references/exploration-strategies.md +341 -0
- package/skills/vscode/references/init-workflow.md +123 -0
- package/skills/vscode/references/manifest-schema.json +16 -0
- package/skills/vscode/vdoc.instructions.md +30 -146
- package/skills/vscode/vdoc.prompt.md +5 -15
- package/skills/windsurf/SKILL.md +67 -0
- package/skills/windsurf/resources/audit-workflow.md +65 -0
- package/skills/windsurf/resources/doc-template.md +67 -0
- package/skills/windsurf/resources/exploration-strategies.md +341 -0
- package/skills/windsurf/resources/init-workflow.md +123 -0
- package/skills/windsurf/resources/manifest-schema.json +16 -0
- package/skills/windsurf/vdoc-workflow.md +3 -13
- package/skills/cursor/vdoc.mdc +0 -176
- package/skills/windsurf/vdoc.md +0 -94
|
@@ -0,0 +1,341 @@
|
|
|
1
|
+
# Exploration Strategies
|
|
2
|
+
|
|
3
|
+
Smart, targeted codebase exploration. Two phases: fingerprint the project, then follow the right archetype playbook.
|
|
4
|
+
|
|
5
|
+
## Phase 1 — Fingerprint
|
|
6
|
+
|
|
7
|
+
Read these high-signal files first (whichever exist) to classify the project. **3-5 reads max.**
|
|
8
|
+
|
|
9
|
+
### Package / Config Files (read 1-2)
|
|
10
|
+
|
|
11
|
+
| File | Ecosystem |
|
|
12
|
+
|------|-----------|
|
|
13
|
+
| `package.json` | Node.js / JavaScript / TypeScript |
|
|
14
|
+
| `pyproject.toml` / `setup.py` / `requirements.txt` | Python |
|
|
15
|
+
| `go.mod` | Go |
|
|
16
|
+
| `Cargo.toml` | Rust |
|
|
17
|
+
| `Gemfile` | Ruby |
|
|
18
|
+
| `pom.xml` / `build.gradle` | Java / Kotlin |
|
|
19
|
+
| `composer.json` | PHP |
|
|
20
|
+
| `*.csproj` / `*.sln` | .NET |
|
|
21
|
+
| `pubspec.yaml` | Dart / Flutter |
|
|
22
|
+
|
|
23
|
+
### Structure Scan
|
|
24
|
+
|
|
25
|
+
- List root directory
|
|
26
|
+
- List `src/` or `app/` or `lib/` (whichever exists)
|
|
27
|
+
|
|
28
|
+
### Entry Points (read 1-2)
|
|
29
|
+
|
|
30
|
+
- README.md (first 50 lines)
|
|
31
|
+
- Main entry file (e.g., `src/index.ts`, `main.py`, `cmd/main.go`)
|
|
32
|
+
|
|
33
|
+
### Determine
|
|
34
|
+
|
|
35
|
+
1. **Primary language(s)** and framework(s)
|
|
36
|
+
2. **Project archetype** — match to a playbook below
|
|
37
|
+
3. **Rough scope** — small (< 20 files), medium (20-100), large (100+)
|
|
38
|
+
|
|
39
|
+
If the project spans multiple archetypes (e.g., monorepo with frontend + API), apply multiple playbooks.
|
|
40
|
+
|
|
41
|
+
---
|
|
42
|
+
|
|
43
|
+
## Phase 2 — Archetype Playbooks
|
|
44
|
+
|
|
45
|
+
Match the detected archetype and follow its playbook. Each defines:
|
|
46
|
+
- **Glob patterns** — files to read, in priority order
|
|
47
|
+
- **What to extract** — what each file category reveals
|
|
48
|
+
- **Feature signals** — patterns that indicate documentable features
|
|
49
|
+
|
|
50
|
+
### Composing Archetypes
|
|
51
|
+
|
|
52
|
+
Most real projects don't fit a single archetype. **Combine playbooks** when needed:
|
|
53
|
+
|
|
54
|
+
- A FastAPI app with AI agent workflows → **Web API** playbook for routes/middleware/auth + read `**/workflows/**`, `**/agents/**`, `**/chains/**`, `**/prompts/**` for the agent layer
|
|
55
|
+
- A Next.js app with a Python microservice → **Full-Stack Framework** + **Web API** playbooks
|
|
56
|
+
- A CLI that wraps an SDK → **CLI Tool** + **Library/SDK** playbooks
|
|
57
|
+
|
|
58
|
+
**How to compose:**
|
|
59
|
+
1. Pick the **primary archetype** (what the project fundamentally is)
|
|
60
|
+
2. Follow its playbook fully
|
|
61
|
+
3. When you encounter directories/patterns that belong to another archetype, pull in that playbook's glob patterns and feature signals
|
|
62
|
+
4. In the exploration log, note which archetypes you composed and why
|
|
63
|
+
|
|
64
|
+
Do not force a project into one archetype. The playbooks are building blocks — use what fits.
|
|
65
|
+
|
|
66
|
+
---
|
|
67
|
+
|
|
68
|
+
### Web API
|
|
69
|
+
|
|
70
|
+
**Signals:** Express, FastAPI, Django REST, Rails, Spring Boot, Gin, Actix, Phoenix, Hono, NestJS
|
|
71
|
+
|
|
72
|
+
| Priority | Glob Pattern | What to Extract |
|
|
73
|
+
|----------|-------------|-----------------|
|
|
74
|
+
| 1 | `**/routes/**`, `**/router.*`, `**/urls.py` | Endpoints, HTTP methods, URL structure |
|
|
75
|
+
| 2 | `**/middleware/**`, `**/middleware.*` | Auth, CORS, rate limiting, logging, error handling |
|
|
76
|
+
| 3 | `**/models/**`, `**/schema*`, `**/migrations/**` | Data model, entities, relationships |
|
|
77
|
+
| 4 | `**/controllers/**`, `**/handlers/**`, `**/views/**` | Business logic per endpoint |
|
|
78
|
+
| 5 | `**/services/**`, `**/lib/**` | Shared logic, external integrations |
|
|
79
|
+
| 6 | `**/config/**`, `.env*`, `**/settings*` | Environment config, feature flags |
|
|
80
|
+
| 7 | `**/tests/**` (skim 2-3) | What's tested reveals what matters |
|
|
81
|
+
|
|
82
|
+
**Feature signals:**
|
|
83
|
+
- Auth routes/middleware → Authentication doc
|
|
84
|
+
- Payment/billing routes → Payments doc
|
|
85
|
+
- File upload handlers → File Management doc
|
|
86
|
+
- WebSocket/SSE handlers → Real-time doc
|
|
87
|
+
- Background jobs/queues → Background Processing doc
|
|
88
|
+
- Email/notification services → Notifications doc
|
|
89
|
+
- Search endpoints → Search doc
|
|
90
|
+
- Admin routes → Admin Panel doc
|
|
91
|
+
|
|
92
|
+
---
|
|
93
|
+
|
|
94
|
+
### Frontend SPA
|
|
95
|
+
|
|
96
|
+
**Signals:** React (CRA/Vite), Vue, Svelte, Angular, Solid
|
|
97
|
+
|
|
98
|
+
| Priority | Glob Pattern | What to Extract |
|
|
99
|
+
|----------|-------------|-----------------|
|
|
100
|
+
| 1 | `**/pages/**`, `**/views/**`, `**/routes*` | Page tree, routing structure |
|
|
101
|
+
| 2 | `**/store/**`, `**/context/**`, `**/state/**`, `**/*slice*` | State shape, data flow |
|
|
102
|
+
| 3 | `**/api/**`, `**/services/**`, `**/hooks/use*` | API integration, data fetching |
|
|
103
|
+
| 4 | `**/components/**` (skim top-level) | Component architecture, shared vs feature |
|
|
104
|
+
| 5 | `**/types/**`, `**/interfaces/**`, `**/*.d.ts` | Data contracts, shared types |
|
|
105
|
+
| 6 | `**/utils/**`, `**/helpers/**` | Shared utilities |
|
|
106
|
+
| 7 | `**/config/**`, `.env*` | Feature flags, API URLs, build config |
|
|
107
|
+
|
|
108
|
+
**Feature signals:**
|
|
109
|
+
- Auth context/store + login pages → Authentication doc
|
|
110
|
+
- Form components + validation → Forms doc
|
|
111
|
+
- Data tables with pagination → Data Display doc
|
|
112
|
+
- Charts/dashboards → Analytics doc
|
|
113
|
+
- Theming/i18n files → Theming / Internationalization doc
|
|
114
|
+
- File upload components → Media Management doc
|
|
115
|
+
|
|
116
|
+
---
|
|
117
|
+
|
|
118
|
+
### Full-Stack Framework
|
|
119
|
+
|
|
120
|
+
**Signals:** Next.js, Nuxt, SvelteKit, Remix, RedwoodJS, Blitz, Astro (SSR)
|
|
121
|
+
|
|
122
|
+
| Priority | Glob Pattern | What to Extract |
|
|
123
|
+
|----------|-------------|-----------------|
|
|
124
|
+
| 1 | `**/app/**/page.*`, `**/pages/**`, `**/routes/**` | UI pages AND API routes — the router is the architecture |
|
|
125
|
+
| 2 | `**/api/**`, `**/server/**`, `**/actions/**` | Server-side logic, server actions |
|
|
126
|
+
| 3 | `**/models/**`, `**/schema*`, `**/prisma/**`, `**/drizzle/**` | Data layer, ORM config |
|
|
127
|
+
| 4 | `**/middleware.*`, `**/middleware/**` | Request pipeline, auth, redirects |
|
|
128
|
+
| 5 | `**/components/**` (skim top-level) | Shared UI components |
|
|
129
|
+
| 6 | `**/lib/**`, `**/utils/**`, `**/services/**` | Shared server + client utilities |
|
|
130
|
+
| 7 | `**/config/**`, `.env*`, `next.config.*`, `nuxt.config.*` | Framework and environment config |
|
|
131
|
+
|
|
132
|
+
**Feature signals:**
|
|
133
|
+
- All Web API signals + all Frontend SPA signals
|
|
134
|
+
- Server actions / mutations → Data Mutation doc
|
|
135
|
+
- ISR/SSG configuration → Rendering Strategy doc
|
|
136
|
+
- Edge functions / middleware → Edge Computing doc
|
|
137
|
+
|
|
138
|
+
---
|
|
139
|
+
|
|
140
|
+
### CLI Tool
|
|
141
|
+
|
|
142
|
+
**Signals:** Commander, Yargs, Click, Typer, Cobra, Clap, oclif, Argparse
|
|
143
|
+
|
|
144
|
+
| Priority | Glob Pattern | What to Extract |
|
|
145
|
+
|----------|-------------|-----------------|
|
|
146
|
+
| 1 | `**/commands/**`, `**/cmd/**`, `**/cli.*` | Command tree, subcommands |
|
|
147
|
+
| 2 | Main entry (`bin/*`, `src/index.*`, `src/main.*`) | Argument parsing, top-level flow |
|
|
148
|
+
| 3 | `**/config*`, `**/*rc*`, `**/settings*` | Config file formats, defaults |
|
|
149
|
+
| 4 | `**/utils/**`, `**/lib/**`, `**/core/**` | Core logic behind commands |
|
|
150
|
+
| 5 | `**/output*`, `**/format*`, `**/display*` | Output formatting (JSON, table, etc.) |
|
|
151
|
+
| 6 | `**/templates/**`, `**/scaffolds/**` | Code generation templates |
|
|
152
|
+
|
|
153
|
+
**Feature signals:**
|
|
154
|
+
- Multiple subcommands → one doc per command group
|
|
155
|
+
- Config file handling → Configuration doc
|
|
156
|
+
- Plugin/extension system → Plugin Architecture doc
|
|
157
|
+
- Interactive prompts → User Interaction doc
|
|
158
|
+
- File I/O operations → File Processing doc
|
|
159
|
+
|
|
160
|
+
---
|
|
161
|
+
|
|
162
|
+
### Library / SDK
|
|
163
|
+
|
|
164
|
+
**Signals:** Published package with `main`/`exports` in package.json, `lib/` with clear public API, type declarations
|
|
165
|
+
|
|
166
|
+
| Priority | Glob Pattern | What to Extract |
|
|
167
|
+
|----------|-------------|-----------------|
|
|
168
|
+
| 1 | Main export (`src/index.*`, `lib/index.*`, `__init__.py`) | Public API surface |
|
|
169
|
+
| 2 | `**/*.d.ts`, `**/types.*`, `**/interfaces.*` | Type contracts, input/output shapes |
|
|
170
|
+
| 3 | `**/core/**`, `**/lib/**` | Internal implementation |
|
|
171
|
+
| 4 | `**/utils/**`, `**/helpers/**` | Supporting utilities |
|
|
172
|
+
| 5 | `**/examples/**`, `**/demo/**` | Usage patterns |
|
|
173
|
+
| 6 | `**/plugins/**`, `**/adapters/**`, `**/providers/**` | Extension points |
|
|
174
|
+
| 7 | `**/tests/**` (skim 2-3) | Edge cases, expected behavior |
|
|
175
|
+
|
|
176
|
+
**Feature signals:**
|
|
177
|
+
- Multiple exported classes/functions → Core API doc
|
|
178
|
+
- Plugin/adapter pattern → Extension Architecture doc
|
|
179
|
+
- Multiple output formats → Serialization doc
|
|
180
|
+
- Caching layer → Performance doc
|
|
181
|
+
|
|
182
|
+
---
|
|
183
|
+
|
|
184
|
+
### Mobile App
|
|
185
|
+
|
|
186
|
+
**Signals:** React Native, Flutter, SwiftUI, Jetpack Compose, Expo, Ionic, Capacitor
|
|
187
|
+
|
|
188
|
+
| Priority | Glob Pattern | What to Extract |
|
|
189
|
+
|----------|-------------|-----------------|
|
|
190
|
+
| 1 | `**/screens/**`, `**/pages/**`, `**/views/**` | Screen tree, navigation structure |
|
|
191
|
+
| 2 | `**/navigation/**`, `**/router*` | Navigation graph, deep linking |
|
|
192
|
+
| 3 | `**/store/**`, `**/state/**`, `**/providers/**` | State management, data flow |
|
|
193
|
+
| 4 | `**/api/**`, `**/services/**`, `**/network/**` | Backend communication, offline sync |
|
|
194
|
+
| 5 | `**/components/**` (skim) | Shared UI components |
|
|
195
|
+
| 6 | `**/native/**`, `**/platform/**`, `**/ios/**`, `**/android/**` | Platform-specific code, native modules |
|
|
196
|
+
| 7 | `**/assets/**` (list only) | Bundled resources |
|
|
197
|
+
|
|
198
|
+
**Feature signals:**
|
|
199
|
+
- Push notification setup → Notifications doc
|
|
200
|
+
- Camera/media access → Media Capture doc
|
|
201
|
+
- Offline storage (SQLite, Realm, AsyncStorage) → Data Persistence doc
|
|
202
|
+
- Deep linking / universal links → Navigation doc
|
|
203
|
+
- Platform-specific native modules → Platform Integration doc
|
|
204
|
+
|
|
205
|
+
---
|
|
206
|
+
|
|
207
|
+
### Data Pipeline / ML
|
|
208
|
+
|
|
209
|
+
**Signals:** Airflow, dbt, Prefect, Dagster, Luigi, Pandas, Spark, TensorFlow, PyTorch, scikit-learn, Jupyter notebooks
|
|
210
|
+
|
|
211
|
+
| Priority | Glob Pattern | What to Extract |
|
|
212
|
+
|----------|-------------|-----------------|
|
|
213
|
+
| 1 | `**/dags/**`, `**/pipelines/**`, `**/flows/**`, `**/workflows/**` | Pipeline definitions, DAGs, task graph |
|
|
214
|
+
| 2 | `**/models/**` (ML or dbt) | Model definitions, training logic or SQL transforms |
|
|
215
|
+
| 3 | `**/sources/**`, `**/extractors/**`, `**/connectors/**` | Data sources, ingestion logic |
|
|
216
|
+
| 4 | `**/transforms/**`, `**/processors/**` | Data transformation logic |
|
|
217
|
+
| 5 | `**/schemas/**`, `**/contracts/**` | Data contracts, validation |
|
|
218
|
+
| 6 | `**/notebooks/**`, `*.ipynb` | Exploratory analysis, experiments |
|
|
219
|
+
| 7 | `**/config/**`, `**/profiles*` | Connection strings, environment config |
|
|
220
|
+
|
|
221
|
+
**Feature signals:**
|
|
222
|
+
- Multiple DAGs/pipelines → one doc per pipeline
|
|
223
|
+
- ML model training → Model Training doc
|
|
224
|
+
- Feature engineering → Feature Store doc
|
|
225
|
+
- Data validation (Great Expectations, Pandera) → Data Quality doc
|
|
226
|
+
- Scheduled runs → Orchestration doc
|
|
227
|
+
|
|
228
|
+
---
|
|
229
|
+
|
|
230
|
+
### Monorepo
|
|
231
|
+
|
|
232
|
+
**Signals:** Turborepo, Nx, Lerna, Rush, Bazel, pnpm workspaces — has `packages/`, `apps/`, or `workspace` config
|
|
233
|
+
|
|
234
|
+
| Priority | Glob Pattern | What to Extract |
|
|
235
|
+
|----------|-------------|-----------------|
|
|
236
|
+
| 1 | Root config (`turbo.json`, `nx.json`, `lerna.json`, `pnpm-workspace.yaml`) | Workspace structure, build pipeline |
|
|
237
|
+
| 2 | `packages/*/package.json` or `apps/*/package.json` | All packages/apps and their dependencies |
|
|
238
|
+
| 3 | `**/shared/**`, `**/common/**`, `**/core/**` | Shared packages that others depend on |
|
|
239
|
+
| 4 | Each app/package entry point (skim) | Purpose of each workspace member |
|
|
240
|
+
|
|
241
|
+
**Then apply the matching sub-archetype playbook** to each significant package/app (e.g., Web API for the backend, Frontend SPA for the frontend, Library for shared packages).
|
|
242
|
+
|
|
243
|
+
**Feature signals:**
|
|
244
|
+
- Shared packages → Shared Infrastructure doc
|
|
245
|
+
- Build/deploy pipeline → Build System doc
|
|
246
|
+
- Inter-package dependencies → Architecture Overview doc (dependency graph)
|
|
247
|
+
|
|
248
|
+
---
|
|
249
|
+
|
|
250
|
+
### Microservices
|
|
251
|
+
|
|
252
|
+
**Signals:** Docker Compose, Kubernetes manifests, multiple services with separate entry points, API gateway, service mesh
|
|
253
|
+
|
|
254
|
+
| Priority | Glob Pattern | What to Extract |
|
|
255
|
+
|----------|-------------|-----------------|
|
|
256
|
+
| 1 | `docker-compose*`, `**/k8s/**`, `**/helm/**`, `**/terraform/**` | Service topology, infrastructure |
|
|
257
|
+
| 2 | API gateway config, `**/gateway/**` | Routing, load balancing, auth gateway |
|
|
258
|
+
| 3 | Each service's entry point and routes (skim) | Service responsibilities, API surface |
|
|
259
|
+
| 4 | `**/proto/**`, `**/graphql/**`, `**/schemas/**` | Inter-service contracts (gRPC, GraphQL) |
|
|
260
|
+
| 5 | `**/queues/**`, `**/events/**`, `**/messaging/**` | Async communication, event bus |
|
|
261
|
+
| 6 | `**/shared/**`, `**/common/**` | Shared libraries across services |
|
|
262
|
+
|
|
263
|
+
**Then apply the Web API playbook** to each significant service.
|
|
264
|
+
|
|
265
|
+
**Feature signals:**
|
|
266
|
+
- Service discovery → Service Mesh doc
|
|
267
|
+
- Event-driven communication → Event Architecture doc
|
|
268
|
+
- Shared vs per-service database → Data Architecture doc
|
|
269
|
+
- Health checks / circuit breakers → Resilience doc
|
|
270
|
+
|
|
271
|
+
---
|
|
272
|
+
|
|
273
|
+
### Infrastructure / IaC
|
|
274
|
+
|
|
275
|
+
**Signals:** Terraform, Pulumi, CloudFormation, Ansible, CDK, Serverless Framework
|
|
276
|
+
|
|
277
|
+
| Priority | Glob Pattern | What to Extract |
|
|
278
|
+
|----------|-------------|-----------------|
|
|
279
|
+
| 1 | `**/main.tf`, `**/stacks/**`, `**/lib/**` (CDK) | Resource definitions, stack structure |
|
|
280
|
+
| 2 | `**/variables*`, `**/inputs*`, `**/config*` | Parameterization, environment configs |
|
|
281
|
+
| 3 | `**/modules/**`, `**/constructs/**` | Reusable infrastructure modules |
|
|
282
|
+
| 4 | `**/environments/**`, `**/stages/**` | Environment-specific overrides |
|
|
283
|
+
| 5 | `**/outputs*`, `**/exports*` | Cross-stack references |
|
|
284
|
+
| 6 | CI/CD config (`.github/workflows/`, `Jenkinsfile`) | Deployment pipeline |
|
|
285
|
+
|
|
286
|
+
**Feature signals:**
|
|
287
|
+
- Networking (VPC, subnets, security groups) → Networking doc
|
|
288
|
+
- Compute (ECS, Lambda, EC2) → Compute Architecture doc
|
|
289
|
+
- Data stores (RDS, DynamoDB, S3) → Data Infrastructure doc
|
|
290
|
+
- CI/CD pipeline → Deployment Pipeline doc
|
|
291
|
+
- Monitoring (CloudWatch, Datadog) → Observability doc
|
|
292
|
+
|
|
293
|
+
---
|
|
294
|
+
|
|
295
|
+
## Fallback — Unknown Archetype
|
|
296
|
+
|
|
297
|
+
If the project doesn't clearly match any archetype:
|
|
298
|
+
|
|
299
|
+
1. List the root directory and `src/` (or equivalent)
|
|
300
|
+
2. Read the top 5 largest files by line count
|
|
301
|
+
3. Read any files with "main", "app", "server", "index", or "core" in the name
|
|
302
|
+
4. Check test files — they reveal what developers think is important
|
|
303
|
+
5. Check CI/CD config (`.github/workflows/`, `Jenkinsfile`) — pipeline steps reveal build/deploy architecture
|
|
304
|
+
|
|
305
|
+
Then propose an archetype to the user: *"This looks like a [X] project. I'll explore it using the [X] playbook. Sound right?"*
|
|
306
|
+
|
|
307
|
+
---
|
|
308
|
+
|
|
309
|
+
## Existing Documentation
|
|
310
|
+
|
|
311
|
+
During fingerprinting, check if the project already has documentation:
|
|
312
|
+
|
|
313
|
+
- `vdocs/_manifest.json` — previous vdoc output
|
|
314
|
+
- `docs/`, `documentation/`, `product_documentation/` — existing docs folder
|
|
315
|
+
- `README.md` (if substantial, beyond basic setup)
|
|
316
|
+
- `*.md` files in the project root
|
|
317
|
+
|
|
318
|
+
**If existing docs are found:**
|
|
319
|
+
|
|
320
|
+
1. **Read the existing docs first** — they are a head start, not waste
|
|
321
|
+
2. **Cross-reference with the actual codebase** — verify claims in the docs against real code. Flag anything that's:
|
|
322
|
+
- **Stale** — docs describe behavior that no longer matches the code
|
|
323
|
+
- **Missing** — code has features not covered in docs
|
|
324
|
+
- **Accurate** — docs match the code (reuse this content, don't rewrite it)
|
|
325
|
+
3. **In the exploration log**, add a section:
|
|
326
|
+
|
|
327
|
+
```markdown
|
|
328
|
+
## Existing Documentation
|
|
329
|
+
| Source | Status | Notes |
|
|
330
|
+
|--------|--------|-------|
|
|
331
|
+
| product_documentation/AUTH_DOC.md | Accurate | Matches current auth flow |
|
|
332
|
+
| product_documentation/API_DOC.md | Stale | 3 new endpoints not documented |
|
|
333
|
+
| (no existing doc) | Gap | RAG retrieval pipeline undocumented |
|
|
334
|
+
```
|
|
335
|
+
|
|
336
|
+
4. **In the Plan (Step 2)**, propose:
|
|
337
|
+
- **Update** for stale docs (specify what changed)
|
|
338
|
+
- **New** for gaps
|
|
339
|
+
- **Keep** for accurate docs (copy/adapt into vdocs/ format)
|
|
340
|
+
|
|
341
|
+
This avoids regenerating documentation that already exists and is correct.
|
|
@@ -2,15 +2,52 @@
|
|
|
2
2
|
|
|
3
3
|
## Step 1 — Explore
|
|
4
4
|
|
|
5
|
-
|
|
5
|
+
Follow the two-phase exploration strategy in `references/exploration-strategies.md`:
|
|
6
6
|
|
|
7
|
-
|
|
8
|
-
|
|
9
|
-
- **Architecture**: monolith vs microservices, frontend/backend split, key patterns (MVC, event-driven, etc.)
|
|
10
|
-
- **Integrations**: third-party services (Stripe, AWS, Redis, etc.)
|
|
11
|
-
- **Entry points**: where requests come in, how they flow through the system
|
|
7
|
+
**Phase 1 — Fingerprint** (3-5 file reads max)
|
|
8
|
+
Read package/config files and directory structure to identify the project's language, framework, and archetype. Also check for existing documentation (`vdocs/`, `docs/`, `product_documentation/`, substantial `*.md` files). If found, read them first — they're a head start. See the "Existing Documentation" section in `references/exploration-strategies.md`.
|
|
12
9
|
|
|
13
|
-
|
|
10
|
+
**Phase 2 — Targeted Exploration** (archetype-specific)
|
|
11
|
+
Apply the matching archetype playbook from `references/exploration-strategies.md`. Read files in priority order using the glob patterns listed. Identify feature signals — each signal maps to a documentable feature. Combine multiple playbooks when the project doesn't fit a single archetype (see "Composing Archetypes" in the strategies file).
|
|
12
|
+
|
|
13
|
+
If no archetype matches, use the Fallback strategy and confirm with the user.
|
|
14
|
+
|
|
15
|
+
Do not skim. Understand how the system actually works before proposing docs.
|
|
16
|
+
|
|
17
|
+
**Important:** Use your built-in file-reading tools (Read, Glob, Grep) to explore. Do NOT create scanner scripts, shell scripts, or any tooling. vdoc is purely AI-driven — no scripts, no build steps, no infrastructure.
|
|
18
|
+
|
|
19
|
+
**Phase 3 — Write Exploration Log**
|
|
20
|
+
After exploring, write `vdocs/_exploration_log.md` documenting what you found:
|
|
21
|
+
|
|
22
|
+
```markdown
|
|
23
|
+
# Exploration Log
|
|
24
|
+
|
|
25
|
+
## Fingerprint
|
|
26
|
+
- **Language(s):** e.g., TypeScript, Python
|
|
27
|
+
- **Framework(s):** e.g., Next.js 14, FastAPI
|
|
28
|
+
- **Archetype(s):** e.g., Full-stack Framework
|
|
29
|
+
- **Scope:** e.g., ~85 files, medium
|
|
30
|
+
|
|
31
|
+
## Files Read
|
|
32
|
+
| # | File | Why | What I Found |
|
|
33
|
+
|---|------|-----|--------------|
|
|
34
|
+
| 1 | package.json | Fingerprint | Next.js 14, Prisma, NextAuth |
|
|
35
|
+
| 2 | src/app/ (listing) | Page tree | 12 routes, 3 API routes |
|
|
36
|
+
| ... | ... | ... | ... |
|
|
37
|
+
|
|
38
|
+
## Feature Signals Detected
|
|
39
|
+
| Signal | Source File(s) | Proposed Doc |
|
|
40
|
+
|--------|---------------|--------------|
|
|
41
|
+
| Auth middleware + login page | middleware.ts, app/login/page.tsx | AUTHENTICATION_DOC.md |
|
|
42
|
+
| Prisma schema with 8 models | prisma/schema.prisma | DATA_MODEL_DOC.md |
|
|
43
|
+
| ... | ... | ... |
|
|
44
|
+
|
|
45
|
+
## Ambiguities / Open Questions
|
|
46
|
+
- Could not determine why Redis is in dependencies — no usage found. Ask user.
|
|
47
|
+
- Payments folder exists but appears incomplete / WIP.
|
|
48
|
+
```
|
|
49
|
+
|
|
50
|
+
This log is your working memory. It feeds directly into Step 2 (Plan).
|
|
14
51
|
|
|
15
52
|
## Step 2 — Plan
|
|
16
53
|
|
|
@@ -0,0 +1,80 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: vdoc-audit
|
|
3
|
+
description: "Audit existing vdocs for stale, missing, or dead documentation. Use when user says 'audit docs', 'check docs', or documentation may be out of sync with code."
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# vdoc audit — Documentation Audit
|
|
7
|
+
|
|
8
|
+
Detect stale, missing, and dead documentation. Report and patch. Do NOT create scripts, shell files, scanners, or any tooling — use your built-in tools (Read, Glob, Grep, Bash for git commands) for everything.
|
|
9
|
+
|
|
10
|
+
---
|
|
11
|
+
|
|
12
|
+
## Step 1 — Read Current State
|
|
13
|
+
|
|
14
|
+
Read `vdocs/_manifest.json`. Load the list of documented features and their metadata.
|
|
15
|
+
|
|
16
|
+
## Step 2 — Detect Stale Docs
|
|
17
|
+
|
|
18
|
+
Run `git log --name-only --since="<last_updated>" --pretty=format:""` or use `git diff` to find all source files that changed since the last audit.
|
|
19
|
+
|
|
20
|
+
Cross-reference changed files against each doc's "Key Files" section to identify which docs are stale.
|
|
21
|
+
|
|
22
|
+
## Step 3 — Detect Coverage Gaps
|
|
23
|
+
|
|
24
|
+
Scan the codebase for significant features not covered by any doc. Look for:
|
|
25
|
+
- New route files / API endpoints
|
|
26
|
+
- New service classes or modules
|
|
27
|
+
- New database models / schema changes
|
|
28
|
+
- New configuration or infrastructure files
|
|
29
|
+
|
|
30
|
+
If you find undocumented features, propose new docs.
|
|
31
|
+
|
|
32
|
+
## Step 4 — Detect Dead Docs
|
|
33
|
+
|
|
34
|
+
Check each doc's "Key Files" section against the actual filesystem. If key files no longer exist, the doc may be dead. Flag it: "PAYMENT_PROCESSING_DOC.md references 3 files that no longer exist — remove or archive?"
|
|
35
|
+
|
|
36
|
+
## Step 5 — Check Cross-References
|
|
37
|
+
|
|
38
|
+
Read each doc's "Related Features" section. Verify that:
|
|
39
|
+
- Referenced doc filenames still exist
|
|
40
|
+
- The described coupling is still accurate (skim the relevant code)
|
|
41
|
+
|
|
42
|
+
## Step 6 — Report
|
|
43
|
+
|
|
44
|
+
Present a clear report:
|
|
45
|
+
|
|
46
|
+
```
|
|
47
|
+
Audit Results:
|
|
48
|
+
|
|
49
|
+
STALE (source files changed):
|
|
50
|
+
- AUTHENTICATION_DOC.md — src/lib/auth.ts changed (added GitHub provider)
|
|
51
|
+
- API_REFERENCE_DOC.md — 2 new endpoints added
|
|
52
|
+
|
|
53
|
+
COVERAGE GAPS (undocumented features):
|
|
54
|
+
- src/services/notification.ts — no doc covers notifications
|
|
55
|
+
|
|
56
|
+
DEAD DOCS (source files removed):
|
|
57
|
+
- LEGACY_ADMIN_DOC.md — all 4 source files deleted
|
|
58
|
+
|
|
59
|
+
CROSS-REF ISSUES:
|
|
60
|
+
- AUTHENTICATION_DOC.md references BILLING_DOC.md which no longer exists
|
|
61
|
+
|
|
62
|
+
CURRENT (no changes needed):
|
|
63
|
+
- DATABASE_SCHEMA_DOC.md
|
|
64
|
+
- PROJECT_OVERVIEW_DOC.md
|
|
65
|
+
|
|
66
|
+
Proceed with fixes?
|
|
67
|
+
```
|
|
68
|
+
|
|
69
|
+
**Wait for user direction**, then:
|
|
70
|
+
- Patch stale docs (re-read source files, update affected sections only)
|
|
71
|
+
- Generate new docs for coverage gaps (use `/vdoc-init` workflow for each)
|
|
72
|
+
- Flag dead docs for user to confirm deletion
|
|
73
|
+
- Fix cross-reference issues
|
|
74
|
+
- Update manifest: bump versions, update `last_updated`, `last_commit`
|
|
75
|
+
|
|
76
|
+
## Rules
|
|
77
|
+
|
|
78
|
+
1. **No scripts.** Do NOT create shell scripts, scanners, or build tools. Use Read/Glob/Grep/Bash(git).
|
|
79
|
+
2. **Report before patching.** Always present findings and wait for user direction.
|
|
80
|
+
3. **No hallucination.** Only report what you verified in the code and filesystem.
|