/wiki

name: wiki
description: >
  Read this repository and keep a wiki about it in its Space, sized to the
  repository: an overview that lists every page, then one page per part or
  flow a newcomer needs, each key sentence tied to the code lines it was read
  from, so Wenlan can tell when the code moved on. Writes the pages that are
  missing and leaves the rest alone; a page whose code changed is brought up
  to date by steep, not here. For a Space connected to the repository, also
  fixes sentences of the repository's own docs the code no longer agrees
  with, for the wiki pull request. Use for "build a
  wiki for this repo", "get to know this repository", "幫這個倉庫建 wiki",
  "認識這個倉庫". Invoked as `/wenlan wiki [space:<name>]`.
argument-hint: "[space:<name>]"
allowed-tools: ["Bash", "Read", "Glob", "Grep", "mcp__plugin_wenlan_wenlan__list_pages", "mcp__plugin_wenlan_wenlan__read_page", "mcp__plugin_wenlan_wenlan__write_page", "mcp__plugin_wenlan_wenlan__page_code_basis", "mcp__plugin_wenlan_wenlan__recall", "mcp__plugin_wenlan_wenlan__doc_fix"]
user-invocable: false

/wenlan wiki

Read this repository and keep a wiki about it in its Space. How many pages it has depends on the repository: a small tool may need five, a large monorepo twenty or more. The overview page lists them all. Each key sentence is tied to the code lines it was read from (a code basis), so Wenlan can tell when the code moved on. The pages are written by the AI. A rerun writes only the pages that are missing. A page whose cited code changed is brought up to date by steep (`/wenlan steep`, or Wenlan's automatic mode), not here: wiki writes new pages, steep keeps them current. Reply in the user's language.

1. Resolve repository and Space

The skill accepts one optional inline token of the form `space:<name>`. The bundled resolver strips it and prints the resolved Space line itself:

raw_args="<the full argument string passed to /wenlan wiki>"
resolved="$("${CLAUDE_PLUGIN_ROOT}/scripts/resolve-space.sh" --cwd "$PWD" --args "$raw_args")"
space="$(printf '%s\n' "$resolved" | cut -f1)"
repo_root="$(git -C "$PWD" rev-parse --show-toplevel)"

If the resolver cannot run (a background run may allow only read-only commands), take the Space from the `space:<name>` token instead.

If the `git rev-parse` fails, say this folder is not a git repository and stop. If `space` is empty, say this folder is not matched to a Space and that `/wenlan wiki space:<name>` names one, then stop. Do not ask a question.

2. Plan the pages

Call `list_pages` with `space="<space>"` once. If it answers that the Space is unknown, this repository has no pages yet: register the Space once with `"$W" spaces add "$space"` (`W` as in step 8), then plan from the repository as below. Do not stop to ask.

Find the overview page by exact title (below). If it exists, call `read_page` on it: its `## Pages` section (`## 頁面` in Chinese) is the plan. Then look over the repository once more for an important part or flow the list misses, such as a new package or a new entry point, and add it to the plan.

If there is no overview, plan from the repository. Look before you plan: `git ls-files` (count and top-level layout), the README and docs folder, the build manifests (`package.json`, `Cargo.toml`, `pyproject.toml`, `go.mod` and the like), the entry points, CI config, and `git log --oneline -50`.

Plan the smallest set of pages that lets a newcomer work in this repository. Organise by parts and flows, not by copying the directory tree.

Always:

| Page | What it answers | English title | 繁體中文 title | |---|---|---|---| | Overview | What the project is, where the entry points are, and the list of pages | `What <project> is` | `<project>是什麼` | | How to run it | Install, build, start | `How to run it` | `怎麼跑起來` | | Known pitfalls | From git log, comments and existing docs | `Known pitfalls` | `已知的坑` |

As the repository needs (each only when there is real code behind it):

• **Architecture or module map**: how the parts fit and what each one owns

(`Module map`, `模組地圖`).

• **One page per major part**: a package, crate, service or directory that

owns real behaviour, titled by what it does.

• **One page per important flow**: from entry to effect, such as

`How a request is handled`; for a single main path, `Main flow` / `主流程`.

• **Data and storage**, **configuration**, **release and deploy**,

**integrations with outside services**.

• **How tests run** (`測試怎麼跑`) when the repository has tests: the layers,

and which are slow.

Let the repository decide the count. As a rough guide, a small repository (under about 50 tracked source files) needs 4 to 6 pages, a medium one 8 to 15, a large monorepo 15 to 30. Never plan more than 30. Do not make a page for a folder that only holds glue, and do not split a topic that fits on one screen.

**Existing docs come first.** When the repository already has a doc that covers a planned topic (an architecture doc, a package's README or REFERENCE, a contributing guide that says how to build and run it), do not plan a page that retells it. Drop the topic from the plan and list the doc in the overview under `## Existing docs` (`## 現有文件` in Chinese) as `` - `<path>`: <what it covers, one line> ``. Plan a page on that topic only for what the doc leaves out, and open it with which doc to read first. Step 7 still checks those docs against the code.

Titles are short noun phrases in the user's language, taken from how they typed the request. When a page already in the Space covers a planned topic (for example an earlier wiki's `Module map`), use that page's exact title in the plan rather than a new one.

3. Decide per page: write or leave

For each page in the plan, find it in the `list_pages` result by exact title, never fuzzy.

• Missing: write it (step 4).
• Present, and listed with a `code_basis` entry in state `pending` whose

`repo_root` is this repository: leave it. It is already on steep's list; say in the re