Clarify has a private root package and a CLI with two names

The CLI answers to a scoped package and a bare binary

The quick start and the core workflow name the same tool two ways. Creating a project runs:

npx @clarify-labs/cli init my-docs
cd my-docs

An unscoped binary called clarify, driven from a scoped package. Later, the core workflow runs npx clarify dev and npx clarify build, where the package name is dropped entirely. The distinction matters for anyone pinning a version in CI, because a dependency line has to use the scoped @clarify-labs/cli name while the invocations in the workflow examples use the bare binary. The monorepo layout explains the split rather than excusing it: apps/ holds the docs and www packages named by the filtered dev scripts, extensions/ holds the editor extension, and packages/ holds the libraries plus the CLI that the scoped name refers to.

The repository root is private and carries no dependencies

The repository's own package.json is not something you install. It is marked private, it has no dependencies block at all, and everything it needs sits in devDependencies: turbo, eslint at 10.6.0, @eslint/js at 10.0.0, typescript-eslint at 8.63.0, eslint-plugin-mdx, eslint-plugin-import-x, eslint-plugin-react-hooks, eslint-plugin-react-refresh, and globals at 17.7.0. Every script is a turbo passthrough, with dev, build, typecheck, lint, lint:fix, and test all forwarding to turbo run and two filtered variants, dev:docs for the docs package and dev:www for the www package. Two details stand out. typescript-eslint sits a full major behind the eslint it plugs into, and the lint stack includes a plugin with a very small footprint, @yinxulai/eslint-plugin-peculiar at 1.0.6, which is an unusual companion to the mainstream plugins around it.

pnpm is pinned at 11.13.1 while the engine floor says 9.0.0

The repository ships pnpm-lock.yaml, pnpm-workspace.yaml, and a turbo.json, so it is a pnpm workspace with task caching layered on top. Its packageManager field pins pnpm at 11.13.1, and its engines block asks for Node 22.13.0 or newer and pnpm 9.0.0 or newer. Those two statements do not agree with each other: 11.13.1 sits well past the declared floor, so a team reading only the engines field would believe it could run on pnpm 9 and then meet whatever separates the two majors. The engines block also makes Node 22.13 a hard floor, which excludes Node 20 outright. Meanwhile the project the CLI generates is told to install with npm, so the toolchain the repository uses and the toolchain it hands to users are two different things.

Two of the three newest tags carry a v and one does not

The version story is visible in three places and it mostly lines up, with one exception. The repository's package.json reads version 0.11.21. The newest release is v0.11.21, published on 26 August 2026, the same day as the last push. The release before it is v0.11.20 on 24 August. The one before that is tagged 0.11.19, with no v, on 13 August. So anything that matches on tag names cannot assume the prefix is present, and the break falls inside a single release series rather than at a series boundary. The cadence itself is fast: three releases across thirteen days at a version still short of 1.0, which fits the staged path the readme describes, from a local CLI outward to typed config, theme tokens, and plugins.

The editor extension installs from a downloaded vsix file

The VS Code extension is not in the marketplace. The route is to download the latest clarify-vscode-extension .vsix package from the GitHub Releases page and then either install it from the command line:

code --install-extension clarify-vscode-extension-*.vsix

or use the Extensions sidebar's Install from VSIX entry, which the readme spells out in four UI steps. The same applies to every update: each new build is a file someone fetches. What the extension does once installed is narrow. It detects a Clarify project by the presence of clarify.ts in the workspace, opens a live preview panel with hot module replacement as MDX, OpenAPI, or config files change, refreshes when you switch content files, resolves the preview route from whichever file is currently open, and exposes a command palette entry for stopping the background server.

Pagefind indexes are generated in dev as well as build

Search is part of the pipeline rather than a script tag, and it runs twice: Pagefind indexes are produced by both clarify dev and clarify build, filtered to the current language and returning highlighted excerpts. That is what makes the multilingual story coherent, since content is organised by locale folder with configurable fallback behaviour and localized navigation and footer labels set in clarify.ts. The AI-facing output works the same way: the build emits raw .md and .openapi artifacts, stable raw-content links, page copy actions, and an llms.txt file. Output itself is one HTML file per route with client-side navigation, copied public assets, and route-prefix support, which is what lets the output/ directory be dropped onto any static host, with plugin hooks for route resolution, virtual modules, and build completion.

AGPL-3.0-only sits under a pitch about owning the renderer

The licence is AGPL-3.0, and package.json narrows it to AGPL-3.0-only, so the network copyleft terms apply with no or-later option and no way to relicense the engine privately. That sits underneath a readme whose central argument is ownership: content stays in Git, the docs build locally, the output is static and portable, the renderer is part of the codebase, and a team can customize without waiting on a hosted platform roadmap. The named comparison is Mintlify, described as a polished hosted documentation platform that Clarify positions itself against as an open-source, codebase-owned publishing engine. The question the readme does not settle is what owning the renderer costs when the renderer is copyleft, which for most teams evaluating a hosted platform is the migration path they actually need to price.

Editorial conclusion

Clarify fits a team that keeps documentation in the same repository as the product, wants OpenAPI references and MDX guides in one build, and is willing to host the output itself. It does not fit a team that needs the renderer under a permissive licence, because AGPL-3.0-only governs the engine, and it does not fit a Node 20 shop. Before adopting it, check the pnpm version your pipeline actually has against the pinned 11.13.1, decide whether the copyleft terms of the renderer are acceptable for your deployment, and confirm whether the VS Code extension being a downloaded .vsix rather than a marketplace listing suits your team.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Project website
3. README
4. Releases
5. taicode-labs/clarify on GitHub