@sandrinio/vdoc 3.0.1 → 3.4.0

package/skills/continue/vdoc.md

@@ -1,157 +1,27 @@
 ---
 name: vdoc
-description: "Generate and maintain feature-centric product documentation. Handles init (explore codebase, plan docs, generate), audit (detect stale/missing/dead docs, patch), and query (route questions via semantic manifest)."
+description: "Use when user says /vdoc, 'document this project', 'audit docs', or asks about existing project documentation, stale docs, undocumented features, or documentation coverage gaps"
 alwaysApply: false
 globs:
 ---
 
 # vdoc — Documentation Generator
 
-You generate and maintain feature-centric documentation for codebases. You have three modes: **init**, **audit**, and **query**.
+Three modes: **init**, **audit**, **query**. All docs live in `vdocs/`. Manifest at `vdocs/_manifest.json` is the semantic index.
 
-All documentation lives in `vdocs/` at the project root. The manifest at `vdocs/_manifest.json` is the semantic index you read first.
+## Init (`/vdoc init`)
 
----
-
-## Mode 1: Init
-
-**Trigger:** User says "document this project" or similar.
-
-### Step 1 — Explore
-
-Read the codebase thoroughly. Identify:
-
-- **Tech stack**: languages, frameworks, databases, ORMs
-- **Features**: authentication, API, payments, notifications, search, etc.
-- **Architecture**: monolith vs microservices, frontend/backend split, key patterns
-- **Integrations**: third-party services (Stripe, AWS, Redis, etc.)
-- **Entry points**: where requests come in, how they flow through the system
-
-Do not skim. Read key files — entry points, config, routes, schemas, middleware.
-
-### Step 2 — Plan
-
-Create `vdocs/_DOCUMENTATION_PLAN.md` listing each proposed doc with a one-line description. Present to user. Suggest merges, additions, or removals. Wait for approval.
-
-### Step 3 — Generate
-
-For each approved doc, read ALL relevant source files and generate using this template:
-
-```markdown
-# {Feature Title}
-
-> {One-line description}
-
----
-
-## Overview
-{What it does, why it exists, how it fits in the system.}
-
----
-
-## How It Works
-{Core logic and flow.}
-{Mermaid diagram(s) — max 7-9 nodes per diagram, split if larger.}
-
----
-
-## Data Model
-{Entities this feature owns. Mermaid ER diagram or table.}
-
----
-
-## Key Files
-| File | Purpose |
-|------|---------|
-| `src/path/file.ts` | What this file does |
-
----
-
-## Dependencies & Integrations
-{External services, internal features, packages this relies on.}
-
----
+Read the detailed workflow at `.continue/references/vdoc/init-workflow.md`.
 
-## Configuration
-| Variable | Purpose | Required |
-|----------|---------|----------|
-| `ENV_VAR` | What it controls | Yes/No |
+Summary: Explore codebase → Plan docs → User approves → Generate using template → Build manifest → Self-review.
 
----
-
-## Error Handling
-{Failure modes, what the user sees, retry logic. Mermaid diagram if non-trivial.}
-
----
-
-## Constraints & Decisions
-{Why it's built this way. What you CANNOT change without breaking things.}
-
----
-
-## Related Features
-{Cross-references to other docs by filename. Blast radius notes.}
-
----
-
-*Generated by vdoc v3.0.0 • Last updated: {timestamp}*
-```
-
-**Writing rules:**
-
-- **Mermaid diagrams are mandatory** in "How It Works". Max 7-9 nodes — split larger flows.
-- **Data Model** must show real entities from the code, not placeholders.
-- **Constraints & Decisions** is the most valuable section. Dig for non-obvious choices. If unclear, write: `Reason: unknown — verify with team`.
-- **Related Features** must reference other doc filenames and explain coupling.
-- **Configuration** must list actual env vars from the code.
-- **Error Handling** — trace what happens when things fail.
-
-### Step 4 — Manifest
-
-Create `vdocs/_manifest.json`:
+## Audit (`/vdoc audit`)
 
-```json
-{
-  "project": "<project-name>",
-  "vdoc_version": "3.0.0",
-  "created_at": "<ISO-8601>",
-  "last_updated": "<ISO-8601>",
-  "last_commit": "<short-sha>",
-  "documentation": [
-    {
-      "filepath": "FEATURE_NAME_DOC.md",
-      "title": "Human-Readable Title",
-      "version": "1.0.0",
-      "description": "Rich semantic description with technology names, patterns, concepts. Detailed enough for AI to route questions to this doc.",
-      "tags": ["keyword-tag"]
-    }
-  ]
-}
-```
+Read the detailed workflow at `.continue/references/vdoc/audit-workflow.md`.
 
-### Step 5 — Self-Review
+Summary: Read manifest → Detect stale/gaps/dead docs → Check cross-refs → Report → Patch with approval.
 
-Verify: every doc has mermaid diagrams, at least 2 constraints, real file paths, actual env vars, cross-references. Manifest descriptions are detailed for semantic routing. No hallucinated content.
-
----
-
-## Mode 2: Audit
-
-**Trigger:** User says "audit docs" or similar.
-
-1. **Read manifest** — load `vdocs/_manifest.json`
-2. **Detect stale** — `git diff` or `git log --name-only --since="<last_updated>"` to find changed source files. Cross-reference with each doc's "Key Files" section.
-3. **Detect gaps** — scan codebase for significant source files not covered by any doc (new routes, services, models, config).
-4. **Detect dead docs** — check each doc's "Key Files" against filesystem. Flag docs referencing deleted files.
-5. **Check cross-refs** — verify "Related Features" links still exist and coupling is accurate.
-6. **Report** — present stale, gaps, dead, cross-ref issues, and current docs. Wait for user direction.
-7. **Patch** — update stale docs, generate new docs for gaps, flag dead docs, fix cross-refs. Update manifest.
-
----
-
-## Mode 3: Query
-
-**Trigger:** User asks any question about the codebase or documentation.
+## Query (any documentation question)
 
 1. Read `vdocs/_manifest.json`
 2. Match question against `description` and `tags` fields
@@ -159,14 +29,6 @@ Verify: every doc has mermaid diagrams, at least 2 constraints, real file paths,
 4. Answer from documented knowledge
 5. If no match, suggest running an audit
 
----
-
-## Naming Convention
-
-Files: `FEATURE_NAME_DOC.md` — uppercase, feature-named, `_DOC` suffix.
-
----
-
 ## Rules
 
 1. **Feature-centric, not file-centric.** One doc per logical feature, not per source file.

package/skills/cursor/RULE.md

@@ -0,0 +1,68 @@
+---
+description: "Use when user says /vdoc, 'document this project', 'audit docs', or asks questions about existing project documentation, stale docs, undocumented features, or documentation coverage gaps"
+globs:
+alwaysApply: false
+---
+
+# vdoc — Documentation Generator
+
+## Overview
+
+Documentation must be feature-centric, plan-approved, and grounded in source code. Never generate docs from assumptions.
+
+## When to Use
+- User says `/vdoc`, "document this project", "audit docs", or asks about documentation
+- Docs are stale, missing, or out of sync with code (documentation drift, undocumented features, coverage gaps)
+- After significant feature work that changed codebase behavior
+
+## When NOT to Use
+- API reference docs (use JSDoc/TSDoc)
+- README files or contribution guides
+- Inline code comments
+
+---
+
+Three modes: **init**, **audit**, **query**. All docs live in `vdocs/`. Manifest at `vdocs/_manifest.json` is the semantic index.
+
+## Init (`/vdoc init`)
+
+Read the detailed workflow at `.cursor/rules/vdoc/references/init-workflow.md`.
+
+Summary: Explore codebase → Plan docs → User approves → Generate using template → Build manifest → Self-review.
+
+## Audit (`/vdoc audit`)
+
+Read the detailed workflow at `.cursor/rules/vdoc/references/audit-workflow.md`.
+
+Summary: Read manifest → Detect stale/gaps/dead docs → Check cross-refs → Report → Patch with approval.
+
+## Query (any documentation question)
+
+1. Read `vdocs/_manifest.json`
+2. Match question against `description` and `tags` fields
+3. Read matching doc(s)
+4. Answer from documented knowledge
+5. If no match, suggest running an audit
+
+## Rules
+
+1. **Feature-centric, not file-centric.** One doc per logical feature, not per source file.
+2. **Mermaid over prose.** Diagram flows. Max 7-9 nodes per diagram.
+3. **Constraints are gold.** Always fill "Constraints & Decisions".
+4. **Rich manifest descriptions.** Pack with specific terms for semantic routing.
+5. **No hallucination.** Only document what exists in code.
+6. **Plan first, always.** Never generate without user-approved plan.
+
+## Common Mistakes
+- **File-centric instead of feature-centric** — Don't create one doc per source file. Group by logical feature.
+- **Documenting aspirations** — Only document what the code actually does today, not planned work.
+- **Skipping the plan** — Generating without user approval leads to rework and coverage gaps.
+- **Oversized diagrams** — Keep Mermaid to 7-9 nodes; split if larger.
+- **Shallow constraints** — "Constraints & Decisions" is the most valuable section. Dig for non-obvious choices.
+
+## Red Flags — STOP
+- Generating docs without an approved plan
+- Documenting something you haven't verified in source code
+- Creating one doc per file instead of per feature
+- Skipping Mermaid diagrams in "How It Works"
+- Writing manifest descriptions too vague for semantic routing

package/skills/cursor/references/audit-workflow.md

@@ -0,0 +1,65 @@
+# Audit Workflow
+
+## Step 1 — Read Current State
+
+Read `vdocs/_manifest.json`. Load the list of documented features and their metadata.
+
+## Step 2 — Detect Stale Docs
+
+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.
+
+Cross-reference changed files against each doc's "Key Files" section to identify which docs are stale.
+
+## Step 3 — Detect Coverage Gaps
+
+Scan the codebase for significant features not covered by any doc. Look for:
+- New route files / API endpoints
+- New service classes or modules
+- New database models / schema changes
+- New configuration or infrastructure files
+
+If you find undocumented features, propose new docs.
+
+## Step 4 — Detect Dead Docs
+
+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?"
+
+## Step 5 — Check Cross-References
+
+Read each doc's "Related Features" section. Verify that:
+- Referenced doc filenames still exist
+- The described coupling is still accurate (skim the relevant code)
+
+## Step 6 — Report
+
+Present a clear report:
+
+```
+Audit Results:
+
+STALE (source files changed):
+  - AUTHENTICATION_DOC.md — src/lib/auth.ts changed (added GitHub provider)
+  - API_REFERENCE_DOC.md — 2 new endpoints added
+
+COVERAGE GAPS (undocumented features):
+  - src/services/notification.ts — no doc covers notifications
+
+DEAD DOCS (source files removed):
+  - LEGACY_ADMIN_DOC.md — all 4 source files deleted
+
+CROSS-REF ISSUES:
+  - AUTHENTICATION_DOC.md references BILLING_DOC.md which no longer exists
+
+CURRENT (no changes needed):
+  - DATABASE_SCHEMA_DOC.md
+  - PROJECT_OVERVIEW_DOC.md
+
+Proceed with fixes?
+```
+
+Wait for user direction, then:
+- Patch stale docs (re-read source files, update affected sections only)
+- Generate new docs for coverage gaps (follow init workflow for each)
+- Flag dead docs for user to confirm deletion
+- Fix cross-reference issues
+- Update manifest: bump versions, update `last_updated`, `last_commit`

package/skills/cursor/references/doc-template.md

@@ -0,0 +1,67 @@
+# {Feature Title}
+
+> {One-line description of what this covers}
+
+---
+
+## Overview
+
+{What it does, why it exists, how it fits in the system.}
+
+---
+
+## How It Works
+
+{Core logic and flow.}
+
+{Mermaid diagram(s) — max 7-9 nodes per diagram, split into multiple if larger.}
+
+---
+
+## Data Model
+
+{Entities this feature owns and their relationships. Mermaid ER diagram or table.}
+
+---
+
+## Key Files
+
+| File | Purpose |
+|------|---------|
+| `src/path/file.ts` | What this file does |
+
+---
+
+## Dependencies & Integrations
+
+{External services, internal features, packages this relies on.}
+
+---
+
+## Configuration
+
+| Variable | Purpose | Required |
+|----------|---------|----------|
+| `ENV_VAR` | What it controls | Yes/No |
+
+---
+
+## Error Handling
+
+{Failure modes, what the user sees, retry logic. Mermaid diagram if the error flow is non-trivial.}
+
+---
+
+## Constraints & Decisions
+
+{Why it's built this way. What you CANNOT change without breaking things.}
+
+---
+
+## Related Features
+
+{Cross-references to other docs by filename. Blast radius — what breaks if this changes.}
+
+---
+
+*Generated by vdoc v3.0.0 • Last updated: {timestamp}*