Create a large, accurate, multi-page Markdown wiki directory for a substantial repository. This skill is optimized for codebases large enough to create maintainer pressure: monorepos, frameworks, compilers, platforms, services, or products with hundreds of thousands of lines of code. Prefer evidence from files over guesses, cover the whole repository at useful granularity, and explain core code, decisions, algorithms, and tradeoffs in dedicated pages.

Confirm or infer:

If not specified, produce a multi-page wiki directory aimed at repository learners and new maintainers.

Use fast local inspection before detailed reading. Prefer , , and language-native metadata commands. Run with Node when useful to generate a structured inventory without loading every file into context.

Recommended first pass:

node <skill_dir>/scripts/repo_snapshot.cjs <repo_root> --output /tmp/repo-snapshot.md

Inspect at least:

Before writing pages, create a short plan for the wiki directory:

Adapt this structure to the repository, but keep the output multi-page and navigable.

Before bulk writing, identify the repository's actual design centers: the primary runtime path, the core data model, boundary interfaces, configuration model, persistence/cache/network layers, extension points, and tests that define behavior. Turn those into named architecture or subsystem pages first. File indexes and module catalogs come later and must not dominate the wiki.

Create and keep a short or equivalent scratch outline while working. It should list the design centers, the source files already read for each one, the main hypotheses, and which wiki pages will explain them. Delete or omit this scratch file from the final wiki unless the user wants process notes.

Prioritize detailed reading in this order:

For each important subsystem, identify:

For each deep-dive page, read enough implementation and tests to support all of these design-quality signals: design/architecture, control or data flow, tradeoffs or decisions, invariants or contracts, failure modes, testing evidence, and maintainer risks. If you cannot support most signals from source, downgrade the page to medium coverage instead of padding it.

Use the outline in as the default directory framework. Adapt file names and headings to the repository instead of forcing irrelevant sections.

Write the first pass in this order:

Do not start by generating hundreds of near-identical file pages. A file index is allowed only as a navigation aid after the conceptual pages are useful.

Do not label pages as generated, do not include repeated numbered maintenance sections, and do not use generic phrases like "needs maintainer confirmation" as a substitute for analysis. Use bounded open questions only after explaining what the code does prove.

The wiki directory should normally include:

Do not produce a short overview. This skill is for codebases where maintainers need serious documentation. The quality checker supports two modes:

Dynamic mode (recommended): Pass the project's lines of code with and let the script compute proportional thresholds. This avoids over- or under-sizing the wiki relative to the project:

node <skill_dir>/scripts/wiki_quality_check.cjs <wiki_dir> --loc <project_loc>

The formula scales words (~4× LOC), files (~1 per 2000 LOC), file references (~7% of LOC), and deep-dive pages proportionally. Anti-padding checks remain fixed.

Language note (CJK / non-English wikis): The word-count and non-blank-line targets are calibrated for English prose, where roughly one token equals one word. Chinese, Japanese, and Korean writing is far more information-dense per character, so the same architecture explained well in Chinese produces a much lower word count. The checker auto-detects the CJK ratio and softens the word/line targets accordingly (a pure-CJK wiki gets roughly half the English word target); structure, file-reference, deep-dive, and anti-padding thresholds are language-independent and are never softened. Even after softening, a CJK wiki may still FAIL the word count — that is acceptable when the anti-padding gates are clean and the design depth is real. Never pad to hit a word number; that trades quality for a metric the skill explicitly forbids.

These profiles are reference baselines for very large projects. For most repositories, prefer mode to get proportional expectations. The checker is an advisory tool, not a hard gate — the real quality standard is design depth, architectural clarity, and usefulness to maintainers.

For an unknown repository, estimate LOC with a quick count (e.g. ) and use . For every substantial top-level directory, create or include a dedicated section/page. For every complex module or core subsystem, prefer a subdirectory with multiple focused pages over one overlong page. Include key files/symbols, how it works, tests, failure modes, and maintainer notes. Prefer adding missing pages and evidence-backed explanations over padding generic prose.

Before finalizing, check:

Run the Node quality gate on the wiki directory and expand the wiki if it fails:

node <skill_dir>/scripts/wiki_quality_check.cjs <wiki_dir> --loc <project_loc>

Use only as reference baselines for very large projects. Prefer for proportional expectations. The checker enforces minimum Markdown file count, word count, non-blank lines, headings, H2 sections, unique backticked file references, fenced code blocks, tables, deep-dive page count, repetition limits, banned padding phrases, and index-page dominance limits.

A page only counts as a qualified deep dive when it has enough words, file references, and distinct design-quality signals. This is intentional: a page named with generic prose should fail the gate.

If the checker passes but a human or follow-up review says the wiki feels superficial, treat that as a real failure. Stop optimizing counts, re-read the core source paths, redesign the wiki around architecture and maintainership, and replace the weak pages rather than defending the metrics.

Use diagrams sparingly but concretely.

Use Mermaid for architecture, sequence, flow, state, and dependency diagrams:

```mermaid
flowchart TD
  CLI["CLI entrypoint"] --> Core["Core orchestration"]
  Core --> Adapter["Platform adapter"]
  Core --> Tests["Behavior covered by tests"]

undefined

Use Graphviz DOT only when the user has requested a documentation site (Rspress), since it requires to render. Prefer Mermaid for plain Markdown wiki output. Graphviz is useful when clustered subgraph layout or complex dependency visualization is clearer than Mermaid:

```dot
digraph G {
  rankdir=LR;
  subgraph cluster_core { label="core"; parser; planner; executor; }
  parser -> planner -> executor;
}

undefined

Use KaTeX for formulas, complexity, scoring, or algorithmic invariants:

The cache hit ratio is $H = \frac{hits}{hits + misses}$, and the lookup path is expected $O(1)$ under normal hash distribution.

A strong repo wiki directory: