For product managers
Review the docs your team ships, without learning Git
Release notes, feature guides and specs now arrive as pull requests, often written by an AI agent. DraftView shows you the finished page, lets you change it the way you would in a document, and turns every change into a suggestion the author can accept in GitHub.
The problem
Sound familiar?
The diff is not the page
A GitHub pull request shows Markdown source with red and green lines. You want to read the page your customers will read, and judge whether it is right.
Feedback gets lost on the way back
Comments in Slack, a pasted Google Doc, a screenshot with arrows. Someone has to copy all of it into the pull request, and something always slips.
AI writes faster than you can check
When an agent opens a doc PR for every feature, someone who knows the product has to confirm it says the right thing before it ships.
How it works
Your part, step by step
Open the review from a link
Your team's doc PRs show up in a queue, or someone sends you a link. You sign in with GitHub or just your email address.
Read and edit the rendered page
Click into any paragraph and type. Add a comment on a sentence. Every change is tracked as a suggestion, never a silent rewrite.
Your edits land in the pull request
On submit, your edits become native GitHub Suggested Changes the author can accept with one click. If you have no GitHub account, a teammate checks and pushes them for you.
Get told when it is fixed
When the author or the agent pushes a change that touches what you commented on, DraftView emails you to come and check it.
What you get
Built for how you review
Editing like a document
Headings, lists, tables, links and code blocks edit in place. Markdown, MDX, MyST, Markdoc and AsciiDoc all render as pages.
Native GitHub suggestions
Nothing lives only in DraftView. Your edits arrive in the PR as Suggested Changes and your comments as review threads.
Review a whole doc, not just a change
Doc reviews (in preview) let you review files on the main branch with no pull request. When a maintainer finishes the review, accepted edits become one PR.
A queue, not a pile of links
Doc PRs in connected repos are added to the team queue on their own, with a status for each one, so you can see what needs you.
What you never have to do
- Learn Markdown or Git
- Clone a repo or open a terminal
- Copy feedback from a document back into GitHub
- Ask an engineer for a preview build to read the page
Know before you choose
- DraftView is for reviewing and editing docs that already live in GitHub. It does not write specs from scratch or host your docs site.
- If your specs live in a wiki or Google Docs and never reach a repo, a wiki tool is a better fit.
- The Free plan covers 2 active reviewers and 2 repos a month, with no card. Team is $29 a month for 5 active reviewers, then $10 each.
Common questions
- Do I need a GitHub account?
- No. You can join your team's DraftView organization with your email address and sign in with a magic link. A teammate with GitHub access checks your review and pushes it to the pull request, because GitHub requires suggestions to come from a GitHub account.
- Will engineers have to change how they work?
- No. They keep working in GitHub. Your edits arrive as Suggested Changes and review comments, the same as any other reviewer's.
- Can I suggest edits to a page that is not in a pull request?
- Yes, with a doc review. A maintainer pins files from a branch, everyone comments and proposes edits, and finishing the review opens one pull request with the accepted edits.
- What does it cost?
- The Free plan covers 2 active reviewers and 2 repos a month, with no card. Team is $29 a month for 5 active reviewers, then $10 each.
Keep reading
Last updated 2026-11-04