# Wiki Creator

> Deep-scan a project and generate structured, DeepWiki-style multi-file Markdown documentation under docs/. Use when the user asks to generate project documentation, create a wiki, write project docs, generate a docs folder, or produce a documentation set for a codebase. Output is Chinese, uses Mermaid diagrams, and is compatible with Docsify display via the docsify-station-creator skill. Supports three detail levels (低/中/高, default 中) controlling how thorough the generated docs are.

- Skill: `garveyhu/wiki-creator` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add garveyhu/wiki-creator`
- Raw SKILL.md: https://api.skillmd.com/api/skills/garveyhu/wiki-creator/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- Author: garveyhu (https://skillmd.com/u/garveyhu)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/garveyhu/wiki-creator

---


# 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](references/scan-checklist.md) and execute a thorough project scan:

1. **Global survey**: List all top-level files and directories. Read `package.json` / `pyproject.toml` / `go.mod` / `pom.xml` etc. to identify tech stack and dependencies.
2. **Entry tracing**: Find and read main entry files. Follow import chains to map core module dependencies.
3. **Architecture mapping**: Identify the project's structural pattern (MVC / MVVM / DDD / microservices / monolith / plugin-based, etc.) by reading key directories and files.
4. **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.
5. **Config & infra**: Scan config files, Dockerfiles, CI/CD pipelines, environment variables.
6. **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](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:

1. **Re-read relevant source files** — do not write from memory of Phase 1 alone. Go back and read the actual code to ensure accuracy.
2. **Write content** following the templates in [references/doc-templates.md](references/doc-templates.md).
3. **Include Mermaid diagrams** — read [references/mermaid-style-guide.md](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.
4. **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 `# heading` as 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:

1. Verify every file references actual project code, not placeholder examples.
2. Verify Mermaid syntax against [references/mermaid-style-guide.md](references/mermaid-style-guide.md) checklist — no `radius`, `font-size`, `%%{init}%%`, no `note` in flowcharts, no unsupported CSS properties.
3. Verify file naming is sequential and consistent.
4. 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.