> ## Documentation Index
> Fetch the complete documentation index at: https://docs.qodo.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Generate a PR summary
> Qodo generates a structured pull request summary to help reviewers quickly understand the scope and impact of a change.
export const AzureIcon = () => ;
Qodo reviews the full codebase, not just the diff, to generate a structured summary that gives reviewers meaningful context before they look at a single line of code. The summary captures the intent of the change, estimates how long the review will take, surfaces high-level suggestions, and diagrams the architecture where relevant.
## What the summary includes
Qodo tags each PR and estimates how long the review will take, so reviewers can prioritize and plan before opening a single file. Tags include: Bug fix, Tests, Enhancement, Documentation, and Configuration changes.
The **Walkthroughs** section breaks down the change in detail:
* **Description:** A plain-language breakdown of what changed and why.
* **Diagram:** An architecture diagram showing the flow and connections introduced by the change.
* **High-Level Assessment:** Suggestions and alternatives for the author and reviewer to consider before or during review.
On Bitbucket Data Center, Qodo needs to upload the diagram as a PNG image, which requires a user with write access to the repository. Without this, Qodo cannot attach the image and omits the diagram section silently, with no error shown in the pull request.
To enable diagrams, create a bot user with `REPO_WRITE` permissions and add the following to your `.secrets.toml`:
```toml theme={null}
[bitbucket_server]
USERNAME=""
PASSWORD=""
```
Do not commit `.secrets.toml` to version control.
Bitbucket Server instances earlier than April 2020 may already have the necessary permissions in place and may not require this step. For more information, see the [Atlassian community discussion](https://community.atlassian.com/forums/Bitbucket-questions/Upload-attachment-to-bitbucket-server-with-REST-API/qaq-p/1351758).
**File Changes** groups modified files by category for a cleaner overview of the change surface.
## How to generate a PR summary
### Manually
Comment on the pull request:
`/agentic_describe`
Qodo acknowledges the request and posts the generated summary directly in the pull request.
### Automatically
Qodo generates a summary automatically when a pull request is opened or updated. To adjust this behavior, configure it using `.pr_agent.toml`. For details, see [Configuration fundamentals](/install-and-configure/configuration-overview).
#### Configure where the summary is posted
By default, Qodo posts the PR summary as a standalone comment and does not modify the pull request description. To publish it in the pull request description instead, or let Qodo choose dynamically, see [Comment location](/code-review/comment-location).
#### Publish the review time estimate as a native label/tag
GitHubGitLabAzure DevOps
As pull request volume grows, seeing the review effort directly in your Git provider's pull request list makes it easier to compare and triage which reviews to tackle first, without opening each one.
Enable **Publish review time estimate label** in the Qodo portal (**Configurations** > **Code review** tab, under **PR Summary**) to have Qodo apply the review time estimate as a native pull request tag (Azure DevOps) or label (GitHub, GitLab), in addition to the estimate already shown inside the summary. It's visible on the pull request and in the pull request list (for example, "10-20 Minutes"), without opening the summary. Disabled by default.
See [Configure Qodo using the portal](/install-and-configure/configuration-overview/portal-configuration#code-review).
## Next steps
* [Configuration fundamentals](/install-and-configure/configuration-overview): Customize how and when summaries are generated.
* [Configuration and command reference](/install-and-configure/configuration-overview/configuration-and-command-reference): All configuration options and PR commands.
* [Comment anatomy](/code-review/comment-anatomy): Understand how Qodo structures findings in pull requests.
## What the summary includes
Qodo tags each PR and estimates how long the review will take, so reviewers can prioritize and plan before opening a single file. Tags include: Bug fix, Tests, Enhancement, Documentation, and Configuration changes.
The **Walkthroughs** section breaks down the change in detail:
* **Description:** A plain-language breakdown of what changed and why.
* **Diagram:** An architecture diagram showing the flow and connections introduced by the change.
* **High-Level Assessment:** Suggestions and alternatives for the author and reviewer to consider before or during review.
Enable **Publish review time estimate label** in the Qodo portal (**Configurations** > **Code review** tab, under **PR Summary**) to have Qodo apply the review time estimate as a native pull request tag (Azure DevOps) or label (GitHub, GitLab), in addition to the estimate already shown inside the summary. It's visible on the pull request and in the pull request list (for example, "10-20 Minutes"), without opening the summary. Disabled by default.
See [Configure Qodo using the portal](/install-and-configure/configuration-overview/portal-configuration#code-review).
## Next steps
* [Configuration fundamentals](/install-and-configure/configuration-overview): Customize how and when summaries are generated.
* [Configuration and command reference](/install-and-configure/configuration-overview/configuration-and-command-reference): All configuration options and PR commands.
* [Comment anatomy](/code-review/comment-anatomy): Understand how Qodo structures findings in pull requests.