Documentation teams

Review docs like published pages before they ship.

Open Git-backed Markdown, MDX, static HTML, and review-hosted Forms as readable pages, then check every section for accuracy, structure, completeness, and release readiness.

Commentary keeps the GitHub PR, source modes, section anchors, and comment threads close without making reviewers start from syntax.

  • Rendered docs
  • Static HTML
  • Review forms
  • Publish readiness

Docs review starts with the reader's page.

Raw diffs show which Markdown lines changed. They do not show whether the article answers the reader's question, whether the steps are complete, or whether the structure is ready to publish.

Writers, engineers, and support should review the rendered page first, with source and GitHub context available when a technical detail needs inspection.

Product surface

A review workspace built around the published page.

Markdown Review, HTML Review, and Forms make the rendered document the center of the workflow while keeping source modes and readiness gates one step away.

Product surfaceMarkdown, HTML, and Forms Review for GitHub-backed docs
  • Readable page renderingReview the same headings, paragraphs, lists, and code blocks readers will scan after publish.
  • Section-level commentsAttach feedback to the exact section that needs accuracy, wording, or completeness work.
  • Source context nearbySwitch to raw Markdown, raw HTML, or diff context when syntax, generated output, or repository history matters.
  • Readiness formsAdd release signoff, docs-as-published-page review forms, and checklist answers to the document being reviewed.
  • Publish readinessResolve comments against a practical checklist before the PR ships.

Docs teams do not review syntax. They review clarity.

Source review still matters, but the primary question is whether the page helps the next reader succeed.

Syntax-first review

  • Reviewers reconstruct the final article from changed Markdown lines.
  • Comments point at source positions instead of the reader-facing section.
  • Accuracy, structure, and completeness get mixed into syntax feedback.

Published-page review

  • Reviewers read the rendered page before inspecting source.
  • Comment pins stay attached to the section that needs work.
  • Publish readiness is checked with GitHub context still nearby.

Commentary keeps the docs workflow intact.

Reviewers read the rendered Markdown first, switch to source modes when syntax matters, and keep app-native feedback attached through revisions.

A docs review from PR to publish.

Use the same short loop for README updates, docs branches, and release notes.

  1. 01

    Open the docs PR, branch, file, or folder.

  2. 02

    Read the rendered page before inspecting source.

  3. 03

    Attach accuracy and wording comments to sections.

  4. 04

    Capture checklist or signoff answers when publish readiness needs a structured gate.

  5. 05

    Resolve feedback and publish from the Git workflow.

Review the next docs change as a document.

Start with Markdown Review or open the security overview for provider and preview boundaries.