The wiki

A project's wiki is one folder of markdown pages inside its repo: what the project is about, what was decided and why, what went wrong, what is still open and how to do the things that took a day to work out. Claude sessions read it before they answer and add to it before a turn ends; you browse it in the project page's Wiki tab.

What it is for

Every Claude session starts with no memory of the ones before it. Claude's own auto memory keeps notes on how to work in a repo (commands, conventions, your preferences), but the project's knowledge (the domain, the decisions and their reasons, the dead ends) usually ends up scattered across transcripts that Claude Code deletes after a while. The wiki is where that knowledge lives instead:

Sessions read it on demand. Each Claude session of a project with a wiki is told where it is and to read its index and follow the links before answering a question the wiki may cover. The pages are never pasted into the prompt; a session opens the ones it needs.
Sessions write to it. When a turn found out something the next person should not have to find out again, the session writes or extends a page by the wiki skill's rules.
People read it too. The pages are plain markdown in the repo, readable anywhere, and they outlive cterm.

How to use it

Set up a wiki

Open the project page and go to the Settings tab, section Wiki.
Leave the folder as wiki or type another one, then press Set up a wiki… and Set it up.
cterm runs the wiki skill's init in the project folder: it makes the folder, a _schema.md that describes the page shape, an index.md, the skill and its Stop hook under the repo's .claude/, and .claude/wiki.json. It keeps anything already there and says what it wrote.
Nothing is committed: the new files wait among the project's unsaved changes in History, where you save them as a version.

The same offer appears in the empty Wiki tab. Only the project's owner or an admin can set one up. If your wiki already lives somewhere else in the repo, type that folder in Wiki folder and press Save instead; from a terminal, cterm project set <owner>/<project> wiki <folder> does the same ("" or off clears it).

Only sessions started after the set-up are told about the wiki.

Browse it

Open the Wiki tab of the project page (it shows only when the project has a wiki, and a Wiki tile above the tabs counts its pages and broken links), or Wiki… in the project's menu (the ⋯ on the sidebar's group head or on the page).
The tab opens on the index. The list below it groups the pages by type; a red number beside a page counts its broken links, and broken only narrows the list to those pages.
Type in the filter to narrow the list by title, id, alias or tag as you type. Press Enter to search the text of every page, with a snippet for each hit; Esc clears the filter.
A page shows its title, its type, status and tag chips, when it was last updated and its path. Links between pages open inside the tab; a link to a page that does not exist is marked. Under the page, Linked from lists the pages that point to it and Broken links the names nothing answers to.
The tab has its own back and forward buttons and Refresh to read the folder again. On a phone it shows one column at a time, with ‹ Pages to go back to the list.

The tab is read-only on purpose. To edit a page by hand, open it from the Files tab; to have Claude edit it, ask a session.

Harvest past sessions into it

A new wiki starts empty, but the project's earlier conversations already found things out. Harvest… in the Wiki tab's head (for the owner or an admin) opens a dialog:

Choose From a day to a day or Picked from the list. Each conversation shows whether its brief was on, whether it was already harvested and whether it is still running.
Tick Again: read the ones harvested already too if you want those read once more.
Leave on And the N project facts of Claude's memory to offer the memory's notes about the project as candidates. Notes on how to work are left out, and the memory itself is never changed.
Read the line that says what the job will read (how many conversations, how much text), then press Start the harvest.

The tab then shows the job's line: waiting, running with what it reads, then the pages it wrote and extended as links, and a warning if the wiki's lint fails afterwards. For a single ended Claude session, Harvest into the wiki in its row menu does the same for that one conversation. Harvested sessions get a book mark in the sidebar and an "in the wiki" chip on the Sessions tab.

Ranked search

When the wiki folder is a collection in qmd, a local search index on the Mac, the filter gets a ranked / text switch, ranked by default. Enter then ranks the pages by their words and, once a session has built the vectors, by meaning, so a question in words other than the page's still finds it. The results say how they were found, and cterm falls back to the text search with a note when qmd cannot answer.

A session sets this up with the skill (wiki.mjs qmd add, then qmd embed); cterm installs nothing and never builds the vectors itself.

How it works

The files are the truth. One page per thing at <folder>/<type>/<id>.md, with front matter (title, type, updated, and optionally tags, aliases, sources, status) and links written [[id]]. The index is generated. Which folder: the project's Wiki setting, else the repo's .claude/wiki.json.
The skill (skills/wiki/, copied into the repo by init) holds the rules and a script with search, query, show, new, index and lint. Its Stop hook sends a session back once when pages it wrote itself fail the lint (a broken link, a stale index, a page without a title), while the session still knows why. Pages other sessions left are not its business: a session that only read the wiki stops without being asked.
The viewer reads the folder fresh at each request through the daemon's wiki routes (wiki.ts), so a page a session just wrote shows at the next Refresh.
The harvest is a claude -p job on the project's Claude login and its executing model, one at a time. The daemon writes one file per conversation (its commits, then its brief's topics or a digest of its transcript); a subagent reads each and keeps decisions, pitfalls, open questions and how-tos; the job searches the wiki, extends rather than duplicates, and runs the index and lint until they pass. At most 25 conversations a run, newest first. Pages cite a commit, a pull request or a file, never a transcript.

Scenarios

Starting a wiki on a project with history

Marta's thesis project has two months of sessions behind it. She opens the project page, sets up a wiki from the Settings tab, and follows the "harvest what the project's past sessions found out" link. The dialog proposes the last weeks, she adds the memory's project facts and starts the harvest. A few minutes later the tab lists a dozen new pages: the choice of statistical test and why, a dataset that turned out to be mislabelled, an open question about the survey. She reads them in History, fixes one wording in the Files tab and saves a version.

A session that checks before it answers

You ask a fresh session why prices are stored as integers. It reads the wiki's index, follows the link to the "money as cents" decision page and answers with the reason and its commit, instead of guessing from the code.

Finding a page you half remember

You remember a page about "the login loop on Safari" but not its name. The text search finds nothing for those words. You switch the filter to ranked, type the question as you would ask it, and the pitfall page about cookie flags comes first.

The project page: where the Wiki tab, its tile and the Settings tab live.
Accounts and projects: who owns a project and may set up or harvest its wiki.
The brief: a session's brief is what the harvest reads first when it was on.
Setup and skills: the wiki skill sits beside the project's other skills.
Task sessions: a task session in a worktree reads the worktree's copy of the wiki.