garveyhu Wiki Creator
Deep-scan a project codebase and generate structured multi-file Markdown documentation under docs/. Output narrative flows top-down: concept → design → implementation → extension. All content in Chinese. Use Mermaid for all diagrams.
详细程度（生成前先确认，默认「中」）
Before scanning, ask the user which detail level (use AskUserQuestion; default to 中 if they don't care). The level controls how thorough the docs are — section depth, code-snippet density, diagram richness. It does NOT prescribe a fixed file count or a canned doc tree: you decide the actual structure dynamically from what the project is (a tiny CLI and a 14-module platform at the same level produce very different trees).
| 档位 | 倾向 | 每篇深度 | 图（Mermaid） |
|---|---|---|---|
| 低（精简） | 只覆盖最核心的少数方面，宁缺毋滥 | 概览为主，章节简短，少代码细节 | 关键处点到即可 |
| 中（标准，默认） | 覆盖项目真实存在的主要方面 | 模块级讲清结构与主流程 | 每个主要领域约 1 张 |
| 高（详尽） | 尽量展开项目各层面 | 逐模块实现走读、边界条件、关键代码片段、跨模块引用 | 流程图 + 时序图 + 类图/ER，多图 |
档位只调"挖多深"，不规定"分几篇"——文件数量、如何分册/合并，全部由你按项目实际动态判断。When unsure, pick 中.
Workflow
Phase 1: Deep Scan
This phase is critical. Do not skip or rush it.
Read references/scan-checklist.md and execute a thorough project scan:
- Global survey: List all top-level files and directories. Read
package.json/pyproject.toml/go.mod/pom.xmletc. to identify tech stack and dependencies. - Entry tracing: Find and read main entry files. Follow import chains to map core module dependencies.
- Architecture mapping: Identify the project's structural pattern (MVC / MVVM / DDD / microservices / monolith / plugin-based, etc.) by reading key directories and files.
- Deep read: For each major module (routing, models, services, controllers, state management, etc.), read representative source files to understand actual implementation — not just directory names.
- Config & infra: Scan config files, Dockerfiles, CI/CD pipelines, environment variables.
- Existing docs: Check for README, CHANGELOG, existing docs/, ADRs, OpenAPI specs.
Output of this phase: A mental model of the project covering: purpose, tech stack, architecture pattern, module structure, data flow, external integrations, and deployment approach.
Phase 2: Plan Document Structure
Based on scan results, determine which document types are relevant. Read references/doc-templates.md for content requirements of each type.
Selection rules:
| Project characteristic | Include these doc types |
|---|---|
| Any project | 项目概览, 代码结构 |
| Has clear module boundaries | 系统架构 |
| Has business logic / workflows | 数据流与核心逻辑 |
| Exposes API endpoints | API 与接口 |
| Uses database / ORM | 数据模型与持久化 |
| Has Docker / CI/CD | 配置与部署 |
| Accepts contributions | 开发指南 |
| Has frontend code | 前端架构 |
| Has auth / security | 安全与认证 |
| Has test suite | 测试策略 |
| Has caching / perf design | 性能与优化 |
File naming: Two-digit prefix + descriptive kebab-case name. Example:
docs/
├── 01-overview.md
├── 02-architecture.md
├── 03-codebase-structure.md
├── 04-core-logic.md
├── 05-api-reference.md
└── 06-deployment.md
Decide the number and split of files dynamically from the project — the detail level only changes how thorough each doc is, never a fixed count or template tree. Do NOT force-create docs for aspects the project doesn't have.
Present the planned structure to the user for confirmation before proceeding to Phase 3.
Phase 3: Generate Documentation
Scale each file's section depth, code-snippet density, and diagram count to the chosen detail level (低 / 中 / 高 — see the table above). For each planned document file:
- Re-read relevant source files — do not write from memory of Phase 1 alone. Go back and read the actual code to ensure accuracy.
- Write content following the templates in references/doc-templates.md.
- Include Mermaid diagrams — read references/mermaid-style-guide.md and follow its rules strictly. Use
classDef+:::for styling, proper node shapes, and the provided color schemes. Every doc should have at least one diagram where applicable. After writing each diagram, run the quick check list at the end of the style guide to avoid render failures. - Maintain narrative continuity — each file should start with a brief context sentence linking it to the previous topic.
Writing rules:
- Pure Markdown only. No HTML.
- No navigation links ("下一篇", "返回目录") — Docsify handles navigation.
- Each file uses exactly one
# headingas page title. - Use
##/###/####for sections. - Code examples must specify language for syntax highlighting.
- Tables for structured data (API params, config items, etc.).
- Content must be accurate — sourced from actual code, not generic boilerplate. If unsure about something, re-read the source.
Phase 4: Review
After generating all files:
- Verify every file references actual project code, not placeholder examples.
- Verify Mermaid syntax against references/mermaid-style-guide.md checklist — no
radius,font-size,%%{init}%%, nonotein flowcharts, no unsupported CSS properties. - Verify file naming is sequential and consistent.
- List generated files to the user with a one-line summary of each.
Pairing with Docsify
After wiki generation, suggest the user invoke docsify-station-creator to create the Docsify site shell that displays these docs.