Catryna Wikinelli Get started

Living documentation · local-first · MCP

Docs your agent
writes, and that
stay alive with the code.

Catryna Wikinelli is a git-versioned knowledge base your AI coding agent searches before it builds and updates after it changes things. It lives as plain .mdx in your repo, and your team reads it in a beautiful viewer. One Claude Code plugin. Per-project docs. No database.

› /plugin marketplace add Davidb3l/Catryna-Wikinelli
Star on GitHub ↗
  • MIT open source
  • Bun + React 19
  • reads .docs/ with zero tooling
writes & updates Claude Code create_doc · update_doc
.docs/
_index.json
architecture/*.mdx
modules/*.mdx
reads & browses Your team viewer · localhost:1307

The problem

Documentation has a half-life.

The doc was true the day it was written. Then the code moved on and nobody told the doc. Every new session your agent relearns the codebase from scratch, and every new teammate inherits the guesswork.

Docs as an afterthought
  • Written once, then left to rot
  • Agents rediscover the codebase every session
  • Onboarding runs on tribal knowledge
  • The wiki lives in a tab nobody opens
Docs in the loop
  • Searched before any change lands
  • Updated in the same session as the code
  • One source both agents and humans trust
  • Versioned, local, and always in reach

What it is

Everything docs-as-code
always promised.

the whole point

Built for agents and humans

Your AI agent writes docs through MCP tools and reads them straight off disk, no round-trip. Humans open the same files in a rich viewer. One source of truth, two native audiences.

create_docupdate_docsearch_docs

local-first

Just files. In your repo.

Docs are .mdx with YAML frontmatter under .docs/. No database, no cloud, works offline, versioned in the same commit as the code it describes.

never stale

Docs that follow the code

Each doc tracks its relatedFiles. Change one and the skill nudges your agent to update the doc in the same session. Stale docs are worse than none.

visuals

Diagrams that aren’t an afterthought

React Flow architecture graphs, tldraw whiteboards, and Mermaid. All first-class block types, themed in Turbo Flow out of the box.

react-flowtldrawmermaid

for the humans

A viewer worth opening

Block-based rendering, fuzzy full-text search (⌘K), version history with diff + one-click revert, and code embeds that jump straight into VS Code, Cursor, or IntelliJ.

⌘K searchdiff & reverteditor deep-links

Show, don’t tell

One file. Two readers.

The agent writes plain MDX with a little frontmatter. Your team opens the exact same file as a rendered page, with headings, code, diagrams, search, and version history. No export step, no second source to keep in sync.

agent writes .docs/modules/auth.mdx 
---
title: "Authentication"
path: "modules/auth"
tags: ["auth", "security"]
relatedFiles: ["src/auth/index.ts"]
---

# Authentication

Login issues a short-lived JWT signed
with the server secret, refreshed on rotate.

```mermaid
sequenceDiagram
  Client->>Server: POST /login
  Server-->>Client: 200 + token
```
localhost:1307/modules/auth ⌘K
modules / auth

Authentication

Login issues a short-lived JWT signed with the server secret, refreshed on rotate.

auth security ↺ 4 revisions

The reflex

One loop keeps
the docs honest.

  1. 01

    Search before you build

    Before writing a feature, the agent searches .docs/ for the existing architecture, patterns, and decisions, instead of rediscovering them from source.

    › search_docs "auth flow"
  2. 02

    Read docs as plain files

    Results carry a file path. The agent just reads .docs/<path>.mdx directly, with no MCP round-trip. Humans read the same file in the viewer.

    › Read .docs/modules/auth.mdx
  3. 03

    Update in the same session

    After changing code a doc describes, the agent updates that doc before finishing, so the knowledge base never drifts from reality.

    › update_doc "modules/auth"

Install

Two lines.
Every repo. Zero config.

Inside Claude Code. The plugin works in any repo, for any session: one install, per-project docs. Prefer manual setup, or a non-Claude agent? There’s a .mcp.json path in the README.

  • MCP server Auto-registered. Self-installs its deps on first run. Stores docs in the .docs/ of whatever project you’re in.
  • Agent skill Teaches Claude to search docs before coding, then update them the moment the code changes.
  • /catryna:viewer Slash command that boots the human docs viewer on localhost:1307.
claude code 
› /plugin marketplace add Davidb3l/Catryna-Wikinelli› /plugin install catryna@catryna-wikinelli
✓ catryna registered · 11 MCP tools · skill active

Questions

The honest
answers.

Local-first means what it says. If something here is unclear, the source is right there to read.

Do I need a database or a cloud account?

No. Docs are plain .mdx files in a .docs/ folder in your repo, with a small JSON index. It works fully offline and commits alongside your code.

Will it slow my coding agent down?

No. Reading a doc is a plain file read with zero tooling. The MCP server only gets involved when the agent writes or searches, and search runs locally over your own files.

Is my code or my docs sent anywhere?

Never. Everything stays on your machine and in your own git remote. No external calls, no telemetry, no accounts.

What if I don’t use Claude Code?

The docs are just files any agent or human can read. Point any MCP-capable client at the server with a .mcp.json, or read and edit the .mdx directly.

How do humans actually view the docs?

Run /catryna:viewer (or bun run dev) to open the local viewer on localhost:1307, with fuzzy search, rendered diagrams, and version history.

Does it lock me in?

No. It is MIT-licensed and your content is portable MDX. Remove the tool tomorrow and you still have every doc in plain text, in your repo.