Skip to content
Docsmith

Product

It reads the change, not the calendar.

Docsmith builds an index of every concrete value your documentation states, then checks each change against it. When something breaks, you get the passage, the evidence and a draft — not a reminder to look into it.
Watches
Any repository on GitHub, GitLab or Bitbucket
Writes to
Review queue, pull request, or your own system
Latency
Median 6.4 seconds per page, per change
Merges
Never — approval is always a person

The index

A page is a set of promises

Prose is hard to check. A promise is not. Docsmith reduces every page to the checkable claims it makes, and it is those claims — not the sentences around them — that a change can falsify.

Symbols
Function, type, constant and method names referenced in prose or code samples.
Literals
Defaults, limits, timeouts, ports, versions — any number a page commits to.
Flags and paths
CLI flags, subcommands, environment variables, file paths and endpoints.
Headers and errors
HTTP header names, status codes and verbatim error strings.
Code samples
Whole blocks, parsed and checked for symbols the change removed.
Front matter
Ownership and the reviewed date, used to route the draft to a person.

Where the draft goes

Three ways out, and you pick per repository

01

Review queue

default

Drafts land in a queue with the diff beside the evidence. Approve, edit before approving, or reject with a reason. Nothing reaches your repository until someone says so.

  • Assign a draft to a person or a team
  • Comment inline on the proposed change
  • Edit the draft before approving — your edits feed the evaluation set
  • Reject with a reason, and the page is not flagged again for that change
02

Pull requests

team and business

Turn it on per repository and approved drafts open as pull requests against a branch, scoped to a path glob so nothing outside your docs directory is ever touched.

  • Branch per draft, named from the commit that caused it
  • The PR body carries the evidence and the originating commit
  • Path-scoped: a monorepo docs site never receives an edit elsewhere
  • Docsmith opens and updates. It never merges.
03

API and CLI

every plan

One endpoint takes a change and a page and returns findings, reasoning, a draft and a diff. If your docs live behind a CMS with no integration, this path works anyway.

  • POST /v1/sync — the same engine the dashboard uses
  • Webhooks on sync.completed and draft.approved
  • docsmith sync runs against a local working tree
  • Usable from a pre-push hook or a CI job

Controls

Everything is off until you turn it on

The failure mode for a tool like this is noise. So the defaults are conservative, the scope is explicit, and the product would rather stay quiet than guess.

Path scoping

Nominate the directories Docsmith may write to. Code is read from anywhere; drafts are written only inside those paths.

Confidence floor

Set the confidence below which a finding is not surfaced at all. The default is 0.6, and most teams raise it in week two.

Ignore rules

Exclude a page, a directory or a glob. Changelogs and archived versions are excluded by default.

Quiet hours

Hold drafts during a release window and deliver them as one batch afterwards, rather than eleven notifications.

Targets

Where your docs already are

  • Markdown and MDX in-repo
  • Docusaurus
  • Mintlify
  • Notion
  • Confluence
  • ReadMe

Not listed? The sync API takes a change and a page and gives you back a draft, which works against anything that can make an HTTP request.

Get started

Point it at one repository.

Free, no card, and the whole product. If nothing on your docs set is stale, that is a useful thing to learn too.

Start freeRead the quickstart