If you write documentation in a docs-as-code workflow, you have probably hit this wall. Your PR is ready. The content is linted and looks good. Now you need a product manager, legal, or a subject matter expert to review it before you merge. And they do not have GitHub accounts.
So you copy the content into Google Docs, send it over, wait for comments, and reconcile the feedback manually. It works, but it is slow and messy.
I built DraftView to fix this.
Why I built it
ProseLint Web handles the linting side well. But the review side, getting the right people to look at the content and leave feedback, is still broken for most teams.
The issue is not that reviewers are unwilling. GitHub is just the wrong tool for them. Asking a legal team member to create an account, navigate a diff view, and figure out inline comments is a big ask for someone who just wants to change a sentence.
What it does
You connect DraftView to a GitHub repository and open a PR. From your dashboard, you generate a password protected review link. You send it to whoever needs to review the content. They open it in their browser and see the documentation rendered as it will look when published, not as raw Markdown or a diff. They can leave inline comments and suggest edits directly in the text.
Back in your dashboard, you see all their feedback tied to the exact file and line. You choose which suggestions to push to GitHub as native Suggested Changes. Nothing reaches GitHub until you decide it should.
Try it
DraftView is live at draftview.app. It is free to try, and free for public repositories.
If you are already using ProseLint Web or AsciiDoc Alive, DraftView is the next step in the same workflow. Lint your content, open the PR, then send a review link to your stakeholders.
If you give it a try, I would love to hear what you think. You can reach me on GitHub or LinkedIn.