> For the complete documentation index, see [llms.txt](https://docs.usepylon.com/pylon-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.usepylon.com/pylon-docs/knowledge-base/articles-and-collections/article-review.md).
# Article Review
Request reviews on articles before publishing to ensure content quality and accuracy.
## Requesting a Review
When an article is ready for feedback, you can request a review from reviewers for the knowledge base. Reviewers can be added in **Review & Publish** in the Settings area of the KB. They will receive a notification when their review was requested and can approve the article or request changes.
You can also add approved reviewers here and enforce review for your knowledge base.
You can request a review on a new draft or on changes to an already-published article. Click **Request Review** in the article header, or select articles in the article list and choose **Request Review** to request reviews in bulk. While a review is pending, the button changes to **Cancel Review Request**.
## Reviews queue
The **Reviews** page in the knowledge base sidebar lists every article awaiting review, with a count of pending reviews. Filter by **Review status** (**Needs review**, **Changes requested**, **Approved**), **Collection**, **Requested from**, and **Visibility**.
Select articles and click **Publish** to publish them together. Publishing requires **Publish articles** permission for those articles, whether or not you're a reviewer.
When **Require review before publishing** is on, a version must be approved before a non-reviewer can publish it. Reviewers with publishing permission can publish without waiting for approval. When the setting is off, a pending review doesn't prevent someone with publishing permission from publishing.
## Review Actions
Reviewers can take one of three actions:
* **Approve** — marks the article as approved and ready to publish
* **Request Changes** — sends the article back to the author for revisions
* **Comment** — leave inline comments on specific parts of the article for more detailed feedback
## Highlight Mode
When a reviewer opens an article that needs review, they'll automatically enter highlight mode — a read-only view that shows exactly what changed:
* **Additions** are highlighted in green
* **Deletions** are shown in red with strikethrough
This makes it easy to scan what's new or modified without accidentally editing the article.
Reviewers can toggle between highlight mode and edit mode at any time using the button in the review banner. Highlight mode is read-only with diff highlighting, while edit mode gives full editing access to make changes directly.
## Comparing Versions
Use the **View changes from** dropdown in the editor header to choose which version to compare against. Options include the last published version, previously approved versions, and older drafts — each labeled with the date, author, and status.
## Previewing a Draft
Click **Preview** in the article header to see your unpublished draft on your live knowledge base site, with your theme applied. A banner reads **You are previewing an article.** Previews are only available to teammates signed in to Pylon and can't be shared with customers.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.usepylon.com/pylon-docs/knowledge-base/articles-and-collections/article-review.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
