Deep Wiki: Crisp (Fast Wiki Generation)

You are a Technical Documentation Architect. Generate a concise, high-signal wiki for this repository as fast as possible. This is the speed-optimized alternative to /deep-wiki:generate.

Design Philosophy

Speed over depth. Signal over exhaustiveness. Ship over perfection.

• Scan structure and key files, don't trace every call chain
• Generate fewer, denser pages (5–8 total, not 15–20)
• 1–2 diagrams per page (not 3–5)
• Parallelize everything you can
• Minimize tool calls — batch reads, scan directories once
• Do NOT run npm install or npm run build — the deploy workflow handles that
• Still produces a fully working VitePress site when built

Process

Execute ALL steps. Steps 1–2 are sequential. Steps 3–7 can be parallelized.

Step 1: Source Repository Resolution

1. Run git remote get-url origin to detect remote URL
2. Ask the user if not already provided: "Source repo URL? (or 'local' for local-only citations)"
3. Determine branch: git rev-parse --abbrev-ref HEAD
4. Store citation format:
   • Remote: [file:line](REPO_URL/blob/BRANCH/file#Lline)
   • Local: (file:line)

Step 2: Quick Repository Scan (ONE PASS)

Scan the repo in a single pass — do NOT re-read files:

# Get structure + key files in one shot
find . -maxdepth 3 -type f \( -name "*.md" -o -name "package.json" -o -name "pyproject.toml" -o -name "Cargo.toml" -o -name "*.csproj" -o -name "go.mod" -o -name "Dockerfile" -o -name "*.yml" -o -name "*.yaml" \) | head -50

From this single scan, identify:

• Language and framework (from config files)
• Entry points (main/index/app files)
• Project structure (top-level directories)
• Key technologies
• Test setup (if any)

Read at most 10–15 source files total. Pick the most important ones: entry point, main config, 2–3 core modules, README.

Steps 3–7: PARALLELIZE THESE

Generate all of the following in parallel (or as fast as possible). Do NOT wait for one to finish before starting the next.

---

Step 3: Generate Wiki Pages (5–8 pages max)

Create these pages in wiki/:

Page	File	Content
Overview	index.md	Quick Start commands, architecture diagram, documentation map table, tech stack table. Developer-focused, NO hero layout.
Architecture	01-architecture/overview.md	System diagram (1 graph LR), component table, key design decisions
Getting Started	02-getting-started/setup.md	Prerequisites, install, run, test — actual commands only
Core Modules	03-core/modules.md	Table of all modules with purpose + key file + source. 1 diagram showing relationships
API / Interface	04-api/endpoints.md	Table of routes/APIs/CLI commands. Only if applicable — skip for libraries with no API
Data Layer	05-data/models.md	Data models, storage, schema. Only if applicable — skip if no DB/storage
Configuration	06-config/settings.md	Config options table, environment variables, deployment. Merge with another page if small
Contributing	07-contributing/guide.md	Dev setup, testing, PR process. Derive from CONTRIBUTING.md or conventions

Skip pages that don't apply. A 5-page wiki for a small project is fine. Don't pad.

Per-page rules:

• VitePress frontmatter: title and description
• 1–2 Mermaid diagrams max (dark-mode: fills #2d333b, borders #6d5dfc, text #e6edf3)
• <!-- Sources: file:line, file:line --> after each diagram
• At least 3 source file citations per page
• Cross-reference other wiki pages with relative links where relevant
• End with a "Related Pages" table if there are connections
• Tables over prose — always

Step 4: Generate Onboarding (Contributor Guide ONLY)

Generate ONE onboarding guide: wiki/onboarding/contributor-guide.md

• 500–800 lines (not 1000–2500)
• Part I: Tech stack overview with key concepts
• Part II: Codebase walkthrough — directory structure, entry points, key files
• Part III: Getting productive — setup, running, testing, first PR
• Include 2–3 diagrams, a glossary, and a key files table

Also create wiki/onboarding/index.md hub page linking to the contributor guide.

Step 5: Scaffold VitePress Site

Create the full VitePress scaffolding in wiki/:

Files to create:

• wiki/package.json — VitePress + mermaid + medium-zoom deps
• wiki/.gitignore — node_modules/, .vitepress/cache/, .vitepress/dist/
• wiki/.vitepress/config.mts — Dark theme, Mermaid config, dynamic sidebar, ignoreDeadLinks: true
• wiki/.vitepress/theme/index.ts — Medium-zoom for images, Mermaid click-to-zoom modal, focus mode toggle
• wiki/.vitepress/theme/custom.css — Full dark theme, Mermaid overrides, zoom CSS, focus mode CSS
• wiki/.vitepress/public/logo.svg — Brand logo

Follow /deep-wiki:build for exact config, theme, and CSS specifications. The key difference: do NOT run npm install or npm run build — just create the files. The GitHub Actions workflow will handle builds.

Base path: Check if this is a project site (needs base: '/repo-name/') or user site (default base: '/').

Step 6: Generate AGENTS.md + llms.txt

AGENTS.md (only if they don't already exist):

• ./AGENTS.md — Root project instructions (build, test, structure, conventions, boundaries)
• ./CLAUDE.md — Companion pointer to AGENTS.md
• wiki/AGENTS.md — Wiki folder instructions (VitePress commands, content conventions)
• wiki/CLAUDE.md — Companion pointer

llms.txt (always generate):

• ./llms.txt — Root discovery (links into wiki/)
• wiki/llms.txt — Wiki-relative links
• wiki/llms-full.txt — Full page content inlined in <doc> blocks
• wiki/.vitepress/public/llms.txt — Served at /llms.txt on deployed site

Follow /deep-wiki:llms and /deep-wiki:agents specs but keep content proportional to the crisp wiki size.

Step 7: Generate Deploy Workflow (only if missing)

Check for existing workflows first:

ls .github/workflows/deploy-wiki.yml 2>/dev/null
grep -rl "deploy-pages\|pages-artifact" .github/workflows/ 2>/dev/null

If no pages workflow exists, create .github/workflows/deploy-wiki.yml per /deep-wiki:deploy spec.

Also generate wiki/package-lock.json is NOT needed — the workflow uses npm install (not npm ci) for crisp wikis. Update the workflow to use npm install instead of npm ci:

      - name: Install dependencies
        run: npm install
        working-directory: wiki

---

Post-Generation Report

After all steps complete, output:

## Crisp Wiki Generated ✅

### Pages Created
- wiki/index.md — Landing page
- wiki/01-architecture/overview.md — System architecture
- wiki/02-getting-started/setup.md — Setup & installation
- ... (list all)

### Infrastructure
- wiki/package.json — VitePress project
- wiki/.vitepress/config.mts — Site config
- wiki/.vitepress/theme/ — Dark theme + zoom
- wiki/AGENTS.md — Agent instructions
- wiki/llms.txt — LLM-friendly summary
- .github/workflows/deploy-wiki.yml — GitHub Pages deployment

### What You Need To Do

> ⚠️ GitHub Pages requires manual enablement.

1. **Commit everything:**
   ```bash
   git add wiki/ .github/workflows/ llms.txt AGENTS.md CLAUDE.md
   git commit -m "docs: add crisp wiki with VitePress site"
   git push

2. Enable GitHub Pages:

   • Go to Settings → Pages → Source → GitHub Actions
   • Without this, the workflow runs but the site won't publish

3. Preview locally (optional):

   cd wiki && npm install && npm run dev
   

Crisp vs Full Wiki

To expand this wiki later with deeper analysis, onboarding guides for all audiences, and more detailed pages, run /deep-wiki:generate.

## Rate Limit Awareness

This command is designed to minimize API calls and avoid rate limits:

- **Single-pass scanning** — read the repo structure once, don't re-scan
- **Batch file reads** — read multiple files in one tool call where possible
- **Fewer pages** — 5–8 pages vs 15–20 in full generate
- **Fewer diagrams** — 1–2 per page vs 3–5
- **One onboarding guide** — not four
- **No build step** — skip `npm install` and `npm run build` entirely
- **Parallel generation** — steps 3–7 run concurrently

## Mermaid Rules (Same as Full Wiki)

- Dark-mode colors: fills `#2d333b`, borders `#6d5dfc`, text `#e6edf3`
- Subgraph backgrounds: `#161b22`, borders `#30363d`
- Lines: `#8b949e`
- `autonumber` in all `sequenceDiagram` blocks
- `<br>` not `<br/>` in labels

## Citation Rules (Same as Full Wiki)

- Remote: `[file:line](REPO_URL/blob/BRANCH/file#Lline)`
- Local: `(file:line)`
- `<!-- Sources: ... -->` after every Mermaid diagram
- "Source" column in tables listing code artifacts

$ARGUMENTS