VMark is a plain-text workspace that treats a workflow file as a workflow
An AI friendly markdown editor.
At a glance
- What is it?
- VMark is a Tauri desktop editor for people who work in plain text alongside an AI assistant, and its distinguishing feature is that it recognises well known artifacts, opening a GitHub Actions workflow as a graph and a package manifest as a dependency tree rather than as a generic tree view. It is local-first, installable from Homebrew, and built on an unusual contribution policy in which issues are accepted and pull requests are not.
- Who is it for?
- VMark fits a developer who edits Markdown, YAML or JSON all day, works with an AI assistant beside them, and wants the editor to understand the format rather than treat every file as text. Skip it if you want a plain editor with no AI integration, if you are on Windows or Linux and want a first-class build, since the README calls those best-effort, or if you plan to send pull requests, which the project does not accept.
- Can I use it commercially?
- Yes. ISC is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 2 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 22, 2026, and from our analysis. They are not legal advice.
Editorial analysis
Both sides work on the same files
The README calls VMark the plain-text workspace where humans and AI collaborate, and it makes one architectural claim: both parties read and write the same artifacts, Markdown, YAML, JSON, TOML, Mermaid, SVG, HTML and code, directly, with no translation layer.
That claim is the product. Most editor plus assistant setups put a chat panel next to an editor and copy code between them, which means the assistant is working on a description of your code rather than on your code. Here the assistant has the files.
The practical consequence is that the file format stays the unit of work, which is why the multi-format support is so wide. Markdown opens in WYSIWYG and source modes, JSON and JSONL, YAML, TOML, Mermaid, SVG, HTML in a sandbox and plain text are all supported, and code files such as `.ts`, `.py`, `.rs`, `.go` and `.css` open as syntax highlighted viewers that you can toggle to edit in place or hand off to your `$EDITOR`.
The project description calls it an AI friendly markdown editor, and the homepage is vmark.app with the documentation at the guide section of the same site. The primary language is TypeScript, the licence is ISC, and the repository is not archived, with the last push on 2026-10-20.
One detail in the README is worth reading as a sign of how the project is maintained. The star history chart at the bottom has a long comment explaining that the chart service stopped serving public repositories after a change on 2026-06-30, so the chart is now self-hosted, that the token wrapped behind it is public by design and should be read-only, and that fine-grained tokens expire and need reissuing when the chart silently reverts to a restricted notice. That is a level of operational honesty that is unusual in a README.
Known artifacts get a purpose-built view
The feature list calls this schema-aware previews, and it is the part that separates VMark from a generic text editor with a Markdown plugin.
A GitHub Actions workflow file opens with a workflow-graph view. A `Cargo.toml`, a `package.json` or a `pyproject.toml` opens with a dependency-tree view. Generic JSON, YAML and TOML get a navigable tree.
The distinction in the README's wording is that when the file is a known artifact, VMark renders the right view, not a generic JSON tree. That is a small idea with a large effect on how long it takes to understand a file you did not write. A workflow file read as a YAML tree tells you there are keys called `jobs` and `steps`. The same file as a graph tells you which job depends on which, and where an artifact passes between them.
The same idea runs through the AI side. If the assistant is editing the same file you are, then a schema-aware view is what both of you are looking at, and the editor is not merely a surface for text but a way of seeing the structure of the thing being edited.
For a team whose repositories are mostly configuration, that is a genuinely different proposition from a Markdown preview. The cost is that the set of recognised artifact types is finite, and the README names only a handful of them, so a format the project has not taught VMark about falls back to the generic tree or the text viewer.
Three editing modes and a keyboard-first editing model
Markdown in VMark has three modes, and the list is short enough to be a design statement rather than a feature list.
There is a WYSIWYG mode built on Tiptap and ProseMirror, a Source Peek mode on F5, and a Source Mode on F6 built on CodeMirror 6. The Peek mode is the interesting one, because it is the compromise that most editors get wrong. You read the rendered document, and the source is a peek away, so the file never stops being a plain text file underneath the presentation.
The multi-cursor model follows the same idea. `Mod + D` selects the next match, `Alt + Click` adds cursors, and `Mod + Alt + ↑↓` places vertical cursors. These are the conventions of a code editor rather than of a document editor, which is consistent with a tool aimed at people who edit configuration and documentation rather than prose.
The Tab Escape feature completes the set. Brackets and quotes are auto-paired, and pressing Tab jumps past a closing character instead of inserting a tab, which is the behaviour that makes auto-pairing usable rather than infuriating when you are typing code inside a Markdown file.
There is a dedicated internationalisation story as well. The README lists 20 or more formatting rules for Chinese, Japanese and Korean text, and ten interface languages including Simplified Chinese, Traditional Chinese, Japanese, Korean, German, Spanish, French, Italian and Brazilian Portuguese, auto-detected on first launch. Six themes ship on macOS, White, Paper, Mint, Sepia, Night and Solarized, while Windows and Linux offer White and Night.
Every shortcut is customizable in Settings, which is the last item in the highlights list and the one that decides whether the keyboard model works for you.
MCP is the integration path, not a plugin marketplace
The AI integration section is short, and the mechanism is the Model Context Protocol. VMark speaks MCP natively, and the README says the installation is one click per assistant under Settings, Integrations, Install.
The supported assistants are named: Claude Desktop, Claude Code, Codex CLI, Antigravity CLI, Grok CLI and opencode. There is also an MCP setup guide in the documentation.
The choice of MCP as the only integration surface is a significant design decision. It means the editor exposes its capabilities through a protocol that every listed assistant already speaks, rather than shipping a bespoke adapter per tool, and it means an assistant that is not on the list can still drive the editor if it speaks MCP. It also means the assistant reaches the files through a server, and the repository shows where that server lives: there is a `server/` directory, and the build instructions require building an MCP sidecar before the desktop app will run.
Alongside the protocol integration there are AI Genies for inline writing assistance, which the README describes as a separate thing from the MCP wiring.
The repository also ships with full configuration for Claude Code, Codex CLI and Antigravity, with `AGENTS.md` holding the conventions and a `.claude/` directory holding rules, skills and subagents. For a project that is developed with assistants in the loop, that is the interesting part of the tooling, and it is worth reading the `AGENTS.md` before contributing anything.
Local-first, with the trade-off stated plainly
The README lists the properties of the product in a single line: free, local-first and format-aware, and the local-first claim is spelled out as no cloud, no accounts and no analytics, with documents staying on the machine.
For a tool that is explicitly designed to sit next to an AI assistant, that is a meaningful position rather than a feature list. The assistant is local, the files are local, and there is no account to create and no service to depend on. The MCP integration works because the assistant runs on the same machine and reaches the editor over a local channel.
The release rhythm backs the impression of a small tool being iterated on daily. The three most recent tags are v0.9.100 on 2026-10-16, v0.9.101 on 2026-10-17 and v0.9.102 on 2026-10-20, with the last push on the same day as the newest tag. Patch numbers climbing by one every day or two is the pattern of a project where a change ships as soon as it is ready, which suits an editor with a lot of small surfaces but also means a version pin is a decision you make often.
The version number in the manifest is 0.9.102, and the package is marked private, so the published artifacts are the desktop builds rather than a library.
Building from source needs a Rust toolchain and one sidecar step
The prerequisites are specific enough to plan a build around. Node.js 22 or newer, pnpm 10.x, where the README notes the requirement as `>=10 <11` and says the install refuses any other major, Rust stable at 1.89 or newer, and the Tauri v2 prerequisites.
git clone https://github.com/xiaolai/vmark.git
cd vmark
pnpm install
# Build the MCP sidecar once. Tauri bundles it as an external binary and it is
# a gitignored build artifact, so a fresh clone does not have it.
pnpm --dir server/mcp build:sidecar
pnpm tauri dev # Development
pnpm tauri build # Production
pnpm check:all # Lint + test + buildThe sidecar step is the one that catches people. The comment in the README explains that Tauri bundles the MCP server as an external binary and that it is a gitignored build artifact, so a fresh clone does not have it, and the build command has to be run once by hand.
The full check is `pnpm check:all`, and the README warns that it runs tests which execute `zsh` and `tokei` and fail without them, with `CONTRIBUTING.md` listing what the complete gate needs beyond a build. The package manifest shows how much machinery sits behind that one command: Vitest for the unit tests with separate browser, gates, shared and soak configurations, Playwright installing WebKit for the browser tests, size-limit, knip for unused exports, Stryker for mutation testing, dependency-cruiser and jscpd for structure and duplication checks, and a set of bespoke lint scripts that check eager chunks, file size, timer isolation, index barrels, shell slots and bespoke buttons.
The stack itself is Tauri v2 in Rust with React 19, TypeScript, Zustand v5, Tiptap, CodeMirror 6 and Tailwind CSS v4.
For users rather than builders, the install path is shorter. On macOS there is a Homebrew formula, and the manual route downloads a disk image from the releases page, with an Apple Silicon build and an Intel build. Windows and Linux have pre-built binaries on the same page, and the README is candid that macOS is the primary platform while the other builds are best-effort.
Issues only, because the code is written by AI
The contributing section is the most unusual thing in the README, and it is a single sentence: VMark is vibe-coded, written entirely by AI under human supervision. Issues are welcome, bug reports and feature requests, but external pull requests cannot be safely merged.
The reasoning is stated. When you file an issue, AI fixes it with the full context of the project's conventions, the test suite and the architecture. There is a bug report template and a feature request template in the issue templates directory, and a page in the documentation explaining why issues rather than pull requests.
Security problems are handled separately, reported privately rather than as issues, following the `SECURITY.md` in the repository root.
Whether this policy is right is not for the project to decide alone. It is coherent as stated, because an AI-written codebase has conventions that are easier to apply than to review, and the test suite is the part a human reviewer would lean on hardest. It also means that outside contributions have to go through the issue tracker, and that the pace of change depends on the maintainer's own loop rather than on the community's.
The repository supports the claim in a visible way. The tree carries `AGENTS.md` and `CLAUDE.md` alongside a `.claude/` and a `.codex/` directory, a `.mcp.json` configuration, and a `.cc-suite/` directory, and the README says the repository ships with full configuration for Claude Code, Codex CLI and Antigravity.
Editorial conclusion
VMark fits a developer who edits Markdown, YAML or JSON all day, works with an AI assistant beside them, and wants the editor to understand the format rather than treat every file as text. Skip it if you want a plain editor with no AI integration, if you are on Windows or Linux and want a first-class build, since the README calls those best-effort, or if you plan to send pull requests, which the project does not accept. Verify first that the toolchain matches your machine, since the pnpm major version is enforced, and that the MCP sidecar build step is part of your setup, because a fresh clone does not have it.
Frequently asked questions
How do I install VMark on macOS?
The README gives a Homebrew formula, `brew install xiaolai/tap/vmark`, and a manual route that downloads a disk image from the releases page, with an Apple Silicon build named `VMark_x.x.x_aarch64.dmg` and an Intel build named `VMark_x.x.x_x64.dmg`. Windows and Linux have pre-built binaries on the releases page, which the README calls best-effort.
What is schema-aware preview in VMark?
When a file is a known artifact, VMark renders a purpose-built view rather than a generic tree. A `.github/workflows/ci.yml` opens with a workflow-graph view, `Cargo.toml`, `package.json` and `pyproject.toml` open with a dependency-tree view, and generic JSON, YAML and TOML get a navigable tree.
Which AI assistants does VMark integrate with?
VMark speaks MCP natively, and the README lists Claude Desktop, Claude Code, Codex CLI, Antigravity CLI, Grok CLI and opencode as supported. The integration is installed from Settings, Integrations, Install, one click per assistant, and a setup guide is linked from the documentation.
Why does building VMark from source need an extra step?
The MCP sidecar has to be built once, because Tauri bundles it as an external binary and it is a gitignored build artifact that a fresh clone does not have. The README gives `pnpm --dir server/mcp build:sidecar` before `pnpm tauri dev` or `pnpm tauri build`, and the prerequisites are Node.js 22+, pnpm 10.x, Rust 1.89 or newer and the Tauri v2 prerequisites.
Can I contribute code to VMark through a pull request?
No. The README states the project is vibe-coded, written entirely by AI under human supervision, that issues are welcome, and that external pull requests cannot be safely merged. Security problems are reported privately rather than as issues, following the repository's `SECURITY.md`.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/xiaolai-vmark)Was this useful?