Automated Review

The work that makes docs stale usually happens in your issue tracker and your repositories. Automated review closes that loop: when a change ships, Docpipe reads it and proposes updates to the documentation it may have affected — so your docs keep pace with your code without anyone remembering to update them.

What triggers a review

• GitHub — a merged pull request. Docpipe reads the merged PR and opens a review for each document it may have made stale.
• Jira — a resolved ticket (one whose status moved into the Done category).
• Linear — a completed issue.

For Jira and Linear, only tickets linked to a document are reviewed. See Jira and Linear for how links are made.

Where the proposals show up

A proposed update isn't applied automatically — it waits for a person. Proposals surface in-app in a few places:

• The Review inbox (Review in the sidebar), under Proposed updates.
• A Proposed updates banner across your document lists, summarizing what's waiting.
• The redline drawer on the affected document itself.

You review each change as a redline and Approve or Reject it — the same review flow described in Verification & staleness.

Turning it on

• GitHub — enable it per repository. On Settings → Integrations → GitHub, under Pull-request review, switch on the repos whose merges should generate proposals. (The GitHub App also needs read access to pull requests.) Which spaces receive GitHub proposals is set per space under Settings → Knowledge.
• Jira and Linear — there's no separate switch. Review follows the connection scope: any resolved ticket in a connected Jira project, or completed issue in a connected Linear team, is reviewed. Narrow the connected projects or teams to narrow what's reviewed.

How quickly it runs

Docpipe sweeps for shipped work hourly, with a weekly reconcile to catch anything missed. GitHub and Linear can also send a webhook so merges and completed issues are picked up within a minute or two; without one, they're caught by the next hourly sweep.