The project wiki

Your team's markdown files, readable and editable on every device — and still just files in your repo.


Teams write things down: the architecture, the runbooks, the decisions, the answers new joiners ask for. Peractor gives those notes a home on every device — a phone, a browser, the Mac, your editor.

It does not give them a database. The files in your repository are the wiki. Everything Peractor holds is a copy, and every copy is throwaway.

That one rule buys a lot. A page is diffed, blamed, branched, and reviewed like the code it describes. A page edited in your editor is just edited — nothing has to be told and there is no direction of sync to get wrong. And the agent working your next run already has the page, because it cloned the repository.

Turn it on

The wiki is off until an admin turns it on, in Settings → General. You choose:

  • One or more folders in the repository — prefilled with docs/. Every markdown file under them is a page. One folder is marked the default, so a new page knows where to go.
  • A branch — prefilled with the repository's default branch. A project can point the wiki at a wiki branch instead, with the trade-off that those pages are not visible to somebody browsing the repository on GitHub.

A project without a wiki has no Wiki screen at all, rather than an empty one.

Reading

Every device holds the whole wiki as text, so it opens instantly and searches with no connection at all. Pages render as markdown, with headings, code blocks, tables, links between pages, and images from the repository.

On a phone, the Wiki tab takes the Triggers slot in the bar while the wiki is on. Triggers is still a row in Settings, where it was before it had a tab.

Editing, and one button

An edit saves to your device the moment you type it. Nothing is lost, and nothing has reached the repository yet.

A pending list shows what this device has changed — each page marked new, edited, or deleted, each with a way to throw the change away. One button commits all of them in a single commit, with a message field carrying a sensible default. Straight to the branch, no pull request: a wiki edit is not a code change and should not wait on a reviewer.

The words are the ordinary ones. "Not committed yet" over the list, "Commit 3 files" on the button, "Discard" on a row.

Two people editing one page

Your device knows which version of a page you started from, so a commit is a three-way merge — the version you started from, the version in the repository now, and your edit.

  • Different parts of the page changed: it merges and commits, and nobody is told anything. This is the common case and it should be invisible. Two people editing two paragraphs merge silently.
  • The same lines changed: you are shown both versions and pick or edit. Only here. Two people editing neighbouring lines of one list will see this — it is what git means by a conflict, and it is what every git user already lives with.

In the editor, it is different on purpose

VS Code already has a markdown editor, and the files are right there on disk. So the extension contributes navigation and search over the wiki folders and opens the real file. Committing is your own git, which you already have a view for. It never grows a second editor for files you already have.

Two things worth knowing

  • Runs already have it. Nothing is staged into a run — the clone contains the wiki because the wiki is the repository. When the wiki is on, the project's standing instructions gain a line naming the folders, so an agent knows where the knowledge is before it starts guessing.
  • Triggers can ignore it. A developer editing docs/ would otherwise fire every repository trigger in the project. Triggers take an ignore list beside their path filter — useful well beyond the wiki, for generated files, changelogs, and lockfiles. Peractor's own wiki commits are already skipped.

Where the repository is not reachable

SetupWhat happens
SSH key onlyWorks. The wiki speaks git, and git speaks SSH.
GitLab or BitbucketWorks, same as GitHub.
A local folder on a self-hosted serverWorks, and never disturbs a working copy: only the wiki's own paths are committed, other staged work is untouched, and it refuses mid-rebase or mid-merge.
No git credential at allNo wiki. The screen says a git connection is needed.

What the wiki is not

  • No pull request per edit — straight to the branch.
  • No drafts that follow you between devices. A working copy is per machine.
  • No rich-text editor. Markdown, with a preview.
  • No page-level permissions. The repository's permissions are the wiki's permissions.
  • Adding new images from a phone is not in the first version. Reading a page that references one works.