Team-Oriented Markdown
A Git client built for documentation, not code.
Pre-alpha: there is no application yet. This repository currently holds the architecture, the decisions behind it, and the code patterns the implementation will follow. Building in public from the first commit — the design came before the first line of code, and it is all in
docs/.
Engineering teams keep their documentation as markdown in Git repositories, and every current option forces a bad trade-off:
| Option | Problem |
|---|---|
| Confluence / Notion | Paid, cloud-bound, disconnected from the code, weak versioning |
| Obsidian + Git plugin | Git is a bolted-on add-on; built for personal notes; closed source |
| VS Code + extensions | Hostile to non-developers; no documentation experience |
| MkDocs / Docusaurus | Read-only output; editing still happens in a code editor |
The differentiator is not the editor — it is the Git workflow as a first-class citizen, designed for documentation:
- Rendered markdown diff — see changes over the formatted document, not
+/-on raw text. Nothing does this well today. - Branching without ceremony — switch branches and watch the docs change; commit and push in a single gesture.
- History and section blame — who wrote this paragraph, and in which PR.
- Assisted conflict resolution — both sides rendered side by side.
- A documentation experience — space navigation, full-text search, wikilinks, images.
Your .md files stay plain files on disk. Any other tool edits the same files without breaking anything. No proprietary format, no mandatory cloud, no account.
Files are the truth, Git is the backbone rather than a plugin, everything works offline, your documents never leave your machine unless you ask them to (Decision 11), and it's MIT — whatever is free today stays free. The full list, with the reasoning behind each one, is in product.md.
Everything is in docs/ — and yes, it is edited the way TOM proposes: markdown, in this repo, reviewed in pull requests.
| Product | What this is, and the non-goals it will not drift into |
| Architecture | The seven packages, the graph, and what enforces it |
| Decisions | Every architectural choice and why — the folder listing reads as a summary |
| Roadmap | What is being built, in what order, and by which package |
| Products | What each feature must do, one folder per feature |
Phase 0: technical spikes. The milestones are in docs/product/roadmap.md.
Watch or star the repository if you want to know when there is something to run.
Contributions are welcome — please read CONTRIBUTING.md first, and in particular the non-goals: TOM deliberately will not become a WYSIWYG editor, a real-time collaboration tool, or a Notion-style workspace.
Security issues: see SECURITY.md — please do not open a public issue.
MIT — see LICENSE.