Docmunk Help
Changes

How Docmunk finds the articles a change affects

6 min readUpdated October 28, 2026

Each time your code changes, Docmunk works out what changed for your customers. Then it looks for the articles that now tell a reader something wrong. It searches wide for articles a change might touch, then keeps only the ones that need an edit.

What Docmunk reads

Docmunk reads the code your team ships, as Product › Code sets it:

  • Follow: your default branch, another branch… you name, or release tags. With release tags, Docmunk reads the code at the newest release tag.
  • Folders: only the folders set to Check. Docmunk never checks changes in a folder set to Read or Hide.
  • Check: when it reads: on every push, once a day, or only when asked.

See Choose when Docmunk checks your code.

From commits to app changes

A check reads each commit on the followed branch since the last check. A merged pull request is one commit there, so Docmunk reads it as one app change. On Changes, it shows under the pull request's title. A commit pushed straight to the branch is an app change of its own.

What Docmunk learns from a change

First, rules with no model set aside what is sure: a commit that changes only tests, docs, build files, other languages, comments, or spacing. Every doubt goes on to the next step.

Then Docmunk reads these facts from the code, with no model:

  • the words on screen the change adds, takes out, or swaps
  • the words it takes out that no other file of the app still shows
  • the screens its files reach, through the code that imports them
  • the feature flags around it

A model then reads the change. It decides whether customers see or do anything different, what kind of change it is, and which areas of the product it touches. A change customers do not see, or one no article could need, stops here. For the rest, Docmunk writes one plain sentence on what a customer sees differently.

How Docmunk picks the articles

An article is a candidate when one of these is true, with no model:

  • It says words the change took out or swapped.
  • It has a picture of a screen the change reaches. A file that every screen uses, such as a layout, does not count.
  • It reads close in meaning to what the change does.
  • It sits in an area the change touches.

Docmunk ranks the candidates: words first, then pictures, meaning, and area. An article that meets more of these ranks higher.

A model then reads the change, its diff, and the likeliest articles, the first eight in full. It counts an article only when one of these is true:

  • The article says something the change made wrong: a step, label, option, default, limit, or behavior.
  • The task the article teaches gains an option, choice, or step its reader needs.

Sharing an area with the change is not enough. For each article it counts, the model names the words that are wrong, and how sure it is. Docmunk keeps an article when the model is at least half sure.

When the model finds wrong words in one article, Docmunk finds every other article that says them. The model reads each one in full, and counts it only when its sentence is wrong for the same reason.

Why Docmunk is strict about which articles

Docmunk sets no limit on how many articles one change reaches. A rename that leaves twenty articles wrong gets edits in all twenty. A change that might matter goes on to the articles, because that costs only a read.

But Docmunk is strict about which articles it counts. Each proposed edit asks a person for a yes or a no. An edit that nobody needs takes that time, and many of them teach people to accept without reading.

How the edit is written

For each article Docmunk counts, the Writer reads the article, the change, and the code. It proposes small edits, each to a whole sentence or list line, with one short sentence on why. When the article is right as it is, the Writer proposes nothing.

Docmunk keeps the edits current:

  • When a later change puts the words back in the app, Docmunk withdraws the edit.
  • Docmunk does not propose the same edit again after you reject it.
  • An edit about code behind a feature flag that is not on for everyone goes to a release group for that flag. See Publish a release group.

When a change adds screens that no area holds, Docmunk treats it as a feature of its own. The Writer names the feature, drafts its articles, and proposes edits to the articles it changes. A second reader checks each draft against the code and your rules before you see it. It fixes what the code settles, and turns the rest into questions for your team.

What you see in Changes

Proposed edits wait on Changes, under To review. Each app change is a card with its title, the sentence on what customers see, and a chip for its kind:

Chip What the change does
New feature Adds something customers can use that was not there before. Its drafted articles show New article.
Changed Changes how something works: an option, field, or step, a default, or the order of steps.
Renamed Changes only words: a label, button, heading, or message.
Removed Takes away a feature, option, or screen.
Look only Changes only the look. The steps stay the same.
Updated feature Changes the app, and Docmunk has no kind on record for it.

Edits that no app change made, such as ones you asked the chat for, wait under Other updates.

Under each card are the articles it asks to update, each with Review. A rename puts every place that says the old words on one line, such as “Save draft” is now “Save” · 3 places in 3 articles. You can accept all the places at once.

To review also lists the app changes that need nothing. Open “2 changes in the app need nothing” to see each one and its reason, such as “Tests only” or “No article needs an edit”.

In the article, the Edits panel shows each proposed edit with its reason: a chip for what it fixes, one sentence on why, and Details with the commits behind it.

An example

A pull request adds a “Time zone” field to the Profile page of your app. The diff puts the words “Time zone” on screen and takes no words out. The model reads the change as Changed.

Three articles are candidates. “Edit your profile” has a picture of the Profile page. “Set up your account” reads close in meaning. “Invite your team” sits in the same area.

The model reads all three. It counts “Edit your profile”: its steps name each field on the page, and the added field is missing. It leaves the other two, because they mention the Profile page but no sentence is wrong.

On Changes, To review shows one card under the pull request's title, with Changed and a sentence such as “People can set a time zone on their profile.” Under it, “Edit your profile” shows 1 update. The edit adds the field to the step, and its reason says the Profile page has a “Time zone” field.

Review proposed edits

Accept or reject each edit, article by article.

Choose when Docmunk checks your code

Set the branch, the folders, and when checks run.

Publish a release group

Send out the edits held for a feature flag.

No proposed edits after a push

Find out why a push made no edits.

Can't find your answer?