Skip to content
notdocs
notdocs
Use itFeaturesEverything notdocs does, from the editor and query blocks to merges, search and agents, with the page that explains each.AgentsGive Claude Code, Cursor or any MCP client the workspace: tokens, tools, resources and prompts.CLIEvery notdocs command: documents, import, comments, tokens and the organization, for a local folder or a hosted workspace.TemplatesEvery built-in template with the file it starts, from a task to a data processing agreement.PricingFree for one person, Solo and Team for a few. What each plan allows.
Move inSwitch from NotionImport a Notion export as typed markdown documents in your repository.Switch from ObsidianImport an Obsidian vault and keep working on the same files.notdocs vs NotionMarkdown in your git repository or pages in Notion's database: how agents reach each, and what each tool does better.notdocs vs ObsidianBoth keep markdown files. What differs is where they live, who edits them, and how.ChangelogWhat changed in notdocs, from the CHANGELOG in the repository.
notdocsAboutWhy the repository should be the workspace, and the decisions notdocs is built on.SecurityWhere data lives, how access is scoped, and how to report a vulnerability.ContactHow to reach notdocs for support, privacy, security and legal matters.
PoliciesLegalEvery policy and agreement that applies to notdocs.

Your repo is the workspace.

Pages, tasks and decisions are markdown files in git. You edit them in a Notion-like workspace; your coding agents edit them over MCP. Nothing syncs, because both of you are editing the same files.

Read the docs

Or hand it to your coding agent

Read https://notdocs.dev/SKILL.md and set up notdocs in this repository.

The agent reads SKILL.md, installs the CLI, initialises the repository and connects MCP.

A markdown file with frontmatter and a notdocs query block, shown beside the page it renders as: properties, prose and a task board. Underneath, the history of the file shows an edit by a person and two changes by a coding agent.

Three moves, and the repository is the workspace.

No migration, no sync job, no second copy of anything. The files you already have get a place to be read, written and worked on.

  1. 1

    Connect a repository

    Install the GitHub App and pick a repo, or point the CLI at a folder on your machine. A docs folder is a workspace already.

  2. 2

    Edit it as pages

    Frontmatter becomes properties, a code fence becomes a board, and a save is a write to the file: a commit when hosted, a change on disk locally.

  3. 3

    Let your agents in

    Claude signs in; an agent that runs unattended gets a token. One MCP server, the same files, and what they change shows up in the history next to what you changed.

notdocs is for solo founders, agencies and engineering teams who ship with agents.

Same document, same moment, one file.

A document open in more than one browser is one session. Everybody types into it and sees everybody's caret; the server writes the markdown file after a pause, and an agent's change to that file lands in the session merged, not lost.

A document open by two people at once: each types a line while the other's caret shows with their name, a coding agent's change to the file is folded into the session, and the repository records one write of the file when the typing pauses.

  • One session per document

    Open a document somebody else has open and you are in it: their keystrokes, the title and the properties as they are typed, and their caret with their name.

  • The server writes the file

    After 1.5 seconds of quiet, 10 seconds at most, and when the last person leaves. One change in the history per pause, not one per keystroke; ⌘S writes now.

  • Agents land in the session

    A write over MCP, a push or a checkout is folded in where the lines differ. Where they collide the session wins, and the file’s version stays in the history.

Sessions run on the local daemon and the hosted service. How a session works, and what it costs

Everything a workspace does, without leaving the repository.

Boards, types, comments, search, merges and agent access: each one is a view of the files, and each one works the same for a person and for a program.

  • Edits merge

    An agent never overwrites your work. Every write carries the version it was read from, two edits to one file are merged, and a real collision comes back as a diff with a recommendation instead of a silent loss.

  • A code fence is a board

    A task board with no database behind it. Drag a card and the frontmatter of that file changes, and the history says who moved it.

  • One history for everyone

    Agents catch up without re-reading everything. People and agents share one change feed, with a cursor an agent polls for what changed since it last looked.

  • Search that reads every page

    Find the page you half remember. Full text for the exact phrase, embeddings for the meaning, in the palette for you and as a tool for the agent.

  • Typed documents

    Documents have shape without rigidity. Page, task, decision, spec, meeting, launch and any type you declare in the repo config, with the schema checked on every write.

  • Comments live in the repo

    Comments your agents can act on. Threads are YAML files next to the documents, committed like everything else, so an agent reads the review, does the work and resolves it.

  • Tokens you can take back

    Give an agent exactly what it needs and nothing more. One project, one scope, the folders it may write. Revoke the token and its next request fails.

A page is a markdown file. Here is what one can hold.

A fence that draws a diagram, a tab that lists what links here, a query that lays itself out on a calendar, a key that publishes a folder as a site, a letter that leaves as a Word file: each is plain text in the repository, shown for what it is.

  • Fences that draw

    Diagrams, file trees and highlighted code without leaving markdown. A mermaid fence is its diagram, a tree fence a file tree, HTML is shown as what it draws, and the file keeps the source.

  • Every link, backwards

    Rename or move a page and nothing breaks. Every link to it is rewritten in the same commit, and the Links tab shows what depends on a page, by wikilink or by path, before you touch it.

  • A calendar and a gallery too

    One query block, five ways to see it. The same block lays its documents on a month grid by their date or shows them as cards with a cover, beside the board, the table and the list.

  • Published by one key

    Publish a handbook, a docs site or a single page by setting one key. visibility: public lists it on your site, on your subdomain or your own domain, and any agent reads the page as markdown at its .md address, with no account.

  • Documents that leave the repository

    Write contracts, invoices and proposals in markdown and send them as Word or PDF. Letters, memos, reports and the legal set (terms, privacy policy, NDA, DPA, SLA) are MDD documents with a letterhead and a signature block, exported to Word or printed to PDF from the page.

And the rest of it.

An assistant drafts inside the project, a Notion export or a vault becomes a workspace, an agent sets the whole thing up from one URL, and a broken link fails the build before it ships.

  • An assistant that asks first

    Ask it about the project, turn a spec into tasks, draft a page or rewrite a selection. It runs with your permissions and shows you what it will write before it writes.

    What it sends, and to whom

  • Move in from Notion or Obsidian

    A Notion export becomes typed pages with its databases as frontmatter; an Obsidian vault keeps its files. A repository that already has markdown gets a survey from notdocs init, which reads it in place or tidies it under one root with the links rewritten.

    Switch from Notion

  • Hand an agent one URL

    notdocs.dev/SKILL.md tells a coding agent how to install the CLI, initialise the repository and connect MCP. notdocs init writes a short section into your CLAUDE.md or AGENTS.md too.

    SKILL.md and llms.txt

  • Broken links never reach main

    notdocs links finds every link, image and wikilink on the branch that reaches nothing, and notdocs lint finds the markdown that renders as text instead of what it is. Both exit non-zero, so they gate CI, and lint --fix repairs what it can in one commit.

    The CLI

Give your agent the same workspace.

One MCP server, generated from the same contract the web app and the CLI use. Locally it runs over stdio against a folder; hosted, over streamable HTTP: Claude and other clients sign in over OAuth, and an agent that runs unattended uses a project token you can revoke.

shell
1# Local: point the MCP server at a folder
2claude mcp add notdocs -- notdocs mcp --serve ./my-project
3
4# Hosted: link a checkout to a workspace, then add the server
5notdocs link --url https://acme.notdocs.dev --project handbook
6claude mcp add notdocs -- notdocs mcp

One tool per operation

The agent sees the same operations you use, with the same inputs. A write returns a conflict instead of overwriting a person.

docs.listdocs.getdocs.createdocs.updatedocs.backlinksquery.runsearchchanges.sincecomments.listcomments.addcomments.resolvetemplates.listbranches.list+ resources, prompts

Works with Claude Code, Cursor and any client that speaks MCP. Set it up

Run it on your laptop, or let us run it against GitHub.

Same code, same files. The hosted service adds people, tokens and a domain; the local daemon adds nothing to your repository but an index folder.

Local

The CLI runs the whole thing on your machine against any folder. No account, works offline.

  • Daemon with the API, the change feed and the index
  • MCP over stdio for the agent on the same machine
  • Index kept inside the folder, in .notdocs/
  • Same editor, same boards, same merges

Hosted

notdocs.dev reads and commits through a GitHub App you install, and serves your organization on its own subdomain.

  • Every save is a commit on the branch you are viewing
  • Pushes from anywhere re-index through a webhook
  • Members, guests and revocable agent tokens
  • Your own domain, and MCP over streamable HTTP

Questions people ask first.

Where does my content live?
In your git repository, as markdown files with YAML frontmatter. The hosted service keeps an index for search, boards and merges, but the files are the record and you can read them with any tool.
What happens when two edits collide?
Every write carries the hash of the version it was read from. The edits are three-way merged against it; a real conflict is returned as a diff with a recommendation instead of being written.
Can two people edit the same document at once?
Yes. A document open in more than one browser is one session: everybody's keystrokes and carets show as they are typed, and the server writes the file after a pause in the typing. A save from an agent or another branch meets the session as a merge. See editing together.
Which agents work with it?
Anything that speaks MCP. Claude and Claude Code sign in over OAuth, Cursor and any other client connect over HTTP with a project token, and on your machine everything runs over stdio. The agents page has the commands.
Does the assistant train on my documents?
No. Model calls go through Vercel AI Gateway to the provider of the model you pick; we do not train anything on your content. The AI disclosure lists exactly what is sent and how to avoid it.
How do I leave?
Uninstall the GitHub App and ask us to delete your account. There is no export step because there is nothing to export, and no fee. See data portability and exit.
What does it cost?
Nothing for one person. Solo and Team are a flat monthly price per organization, not per seat. See pricing.

Point it at a repository.

A docs folder is enough. Sign in, install the GitHub App, and the pages are there.

Read the docs