CodeRabbit Documentation - AI code reviews on pull requests, IDE, and CLI

CodeRabbit’s custom reports use natural language prompts to generate exactly the insights your team needs. Instead of fixed templates, you describe what you want and CodeRabbit creates tailored reports with your preferred format, data, and structure.

New to CodeRabbit reports? Start with the reports overview to understand the basics before diving into customization.

What you can customize

Content & data

Choose specific pull request information, comments, CI/CD status, and linked issues to include in your reports.

Format & structure

Define report layout using markdown formatting, tables, bullet points, and custom grouping patterns.

Filtering & sorting

Include or exclude PRs based on labels, status, team members, or custom criteria you define.

Language support

Generate reports in multiple languages by specifying your preferred language in the prompt.

Creating Custom Report Templates

Basic Structure

A custom report template consists of instructions that tell CodeRabbit what information to include and how to present it. Here’s a basic example:

Please provide a summary of:
- All merged pull requests
- Critical bug fixes
- Code review discussions

Group by:
- Repository
- Team

Format using:
- Bullet points for changes
- Tables for statistics

Example for different languages

Japanese:

レポートを英語ではなく日本語で送信してください。

以下の要約を提供してください：
- すべてのプルリクエスト活動
- コードレビューの議論

French:

Veuillez envoyer le rapport en français et non en anglais.

Veuillez fournir un résumé de :
- Toutes les activités de demandes de fusion
- Discussions sur la révision de code

Available Data Points

Your custom reports can access the following PR information that you can reference in your prompts:

Pull Request Status

Contained within the <pr_details> tag.

Merged: boolean (true/false) - Whether the PR has been merged
Draft: boolean (true/false) - Whether the PR is in draft state
State: string (“open”/“closed”) - Current state of the PR
Mergeable: boolean (true/false) - Whether the PR can be merged
Is stale: boolean - Whether PR has been inactive for over 168 hours
PR Stage: string - The current stage of open PRs in Open or Draft state, can be one of:
- “Needs Author Action” - PR requires author attention due to merge conflicts, draft status, or requested changes
- “Waiting for Author to Merge” - PR has approvals and is ready for author to merge
- “Waiting for Code Reviews” - PR is waiting for reviewers to approve
- undefined - PR is not in an open state (is merged or closed)

Basic Information

Contained within the <pr_details> tag.

Pull request number: number - The PR’s identifier
Title: string - PR title
URL: string - Link to the PR
Author name: string - PR creator’s username
Created at: datetime - When the PR was created
Last activity: datetime - Most recent activity timestamp
Closed at: datetime (if applicable) - When the PR was closed
Source branch: string - Source branch name
Target branch: string - Target branch name
Labels: array of strings - All labels applied to the PR
Reviewers: array of strings - Assigned reviewers’ usernames

Summarized PR Details

<pr_description>: string - Contains the body of your pull request (aka the PR description at the top of the PR page).
<file_changes_summary>: string - Contains a file by file summary of the changes made in the PR in markdown format. This summary is generated by CodeRabbit AI during the PR review process. This includes several sections for each file that was changed:
- filename: string - The name of the file that was changed.
- AI-generated summary of changes: markdown - An overall summary of the changes made in the file.
- Alterations to the declarations of exported or public entities: markdown - A more specific breakdown of the changes made to the file such as exactly what was added, removed, or modified.

Comments

<pr_comments>: array of comment objects - Contains all the comments made on the PR.
<comment>: object - Each individual comment is wrapped in this tag and is an object with the following properties:
- <comment_author_username>: string - The username of the comment author.
- <comment_created_at>: datetime - The date and time the comment was created.
- <comment_updated_at>: datetime - The date and time the comment was last updated.
- <comment_body>: markdown - The content of the comment.

CI/CD Check Status

<pr_checks>: array of check objects - Contains all CI/CD checks for the PR. GitHub Only.
<pr_check>: object - Each individual check is wrapped in this tag and is an object with the following properties:
- <pr_check_name>: string - The name of the CI/CD check.
- <pr_check_status>: string - The status of the check (e.g., “success”, “failure”, “in_progress”, “canceled”).
- <pr_check_url>: string - The URL to view the detailed results of the check.

Here’s an example prompt that uses these data points:

Example prompt

Use the <overall_instructions> to guide the content of the summary. Use the format shown in <example> but do not include or refer the example's content in the final summary/report.

<overall_instructions>
Generate a summary of each pull request in the following bullet point format:

- PR Link: Provide a hyperlink to the pull request from the 'URL:' value
- Title: Provide the value of the 'Title:' field
- PR State: Provide the state of the PR based on the following conditions:
  - If 'Merged: true' set 'PR State: 🔀 Merged'
  - Else If 'Draft: true' set 'PR State: 📝 Draft'
  - Else If 'State: open' or 'State: active' set 'PR State: 💬 Open'
  - Else If 'State: closed' or 'State: DECLINED' and 'Merged: false' set 'PR State: 🔒 Closed'
  - Else set 'PR State: ❓ Unknown'
  - If the PR is stale, add '⚠️ Stale' at the end of the PR State.
- Mergeable (if PR State is not 'Merged'): Provide the mergeable status of the PR as 'Mergeable' or 'Not Mergeable' based on the "Mergeable: " value.
- PR Stage (if PR State is not 'Merged'): Provide the stage of the PR based on the "PR Stage: " value.
- Summary: In under 50 words provide a short summary of the PR.
- Comments: In under 50 words provide a short summary of all comments found within <pr_comments>, including each comments author username from <comment_author_username>. If there are no comments available, output 'No comments'.
</overall_instructions>

<example>
- **PR Link:** [#3001](https://github.com/mygithuborg/myrepo/pull/3001)
- **Title:** PR Title
- **PR State:** 💬 Open
- **Mergeable:** Mergeable
- **PR Stage:** Waiting for Code Reviews
- **Summary:** Summary of the PR.
- **Comments:** Summary of the PR comments or No comments.

- **PR Link:** [#302](https://github.com/mygithuborg/thatrepo/pull/302)
- **Title:** PR Title
- **PR State:** 💬 Open
- **Mergeable:** Mergeable
- **PR Stage:** Waiting for Author to Merge
- **Summary:** Summary of the PR.
- **Comments:** Summary of the PR comments or No comments.

- **PR Link:** [#3](https://github.com/mygithuborg/myotherrepo/pull/3)
- **Title:** PR Title
- **PR State:** 🔀 Merged
- **Summary:** Summary of the PR.
- **Comments:** Summary of the PR comments or No comments.

- **PR Link:** [#14](https://github.com/mygithuborg/frontend/pull/14)
- **Title:** PR Title
- **PR State:** 💬 Open
- **Mergeable:** Mergeable
- **PR Stage:** Needs Author Action
- **Summary:** Summary of the PR.
- **Comments:** Summary of the PR comments or No comments.

- **PR Link:** [#13005](https://github.com/mygithuborg/backend/pull/13005)
- **Title:** PR Title
- **PR State:** 🔀 Merged
- **Summary:** Summary of the PR.
- **Comments:** Summary of the PR comments or No comments.

- **PR Link:** [#3006](https://github.com/mygithuborg/myrepo/pull/3006)
- **Title:** PR Title
- **PR State:** 🔀 Merged
- **Summary:** Summary of the PR.
- **Comments:** Summary of the PR comments or No comments.

- **PR Link:** [#3007](https://github.com/mygithuborg/myrepo/pull/3007)
- **Title:** PR Title
- **PR State:** 📝 Draft
- **Mergeable:** Not Mergeable
- **PR Stage:** Needs Author Action
- **Summary:** Summary of the PR.
- **Comments:** Summary of the PR comments or No comments.
</example>

Formatting options

CodeRabbit supports full markdown formatting in your custom reports:

Text formatting

Bold, italic, code, and regular text with headers using #, ##, ###.

Lists & tables

Bullet points, numbered lists, and structured tables for organized data presentation.

Links & blocks

Hyperlinks to PRs, code blocks for examples, and any other standard markdown elements.

Headers and Titles

The name you give to each report in the CodeRabbit menu will be used for the first line of any report or the subject for emails. For example if your report is named Executive Summary Template then this string will appear on the subject of your emails and start of all message chains. When using the Preview Report button in the CodeRabbit menu, the subject will begin with Preview: <report name>. The reports will also have an overall title describing the report content such as Pull Request Summary Report (January 2025). To change these details of this overall title you should include specific instructions in your custom prompt with examples such as:

- Do not add a date to the titles like "Pull Request Summary Report (January 2025)" it should just be "Pull Request Summary Report"

Language Support

You can generate reports in multiple languages by specifying the ISO language code in your template. For example:

Language: frPlease provide a summary of:- All pull request activities- Code review discussions

Advanced Features

Filtering

Include specific filtering instructions in your template:

Include only:- PRs with "critical" or "bug" labels- Changes to production code- Reviews from senior developersExclude:- Automated commits- Documentation changes- Dependencies updates

Custom Grouping

Organize information using custom grouping rules:

Group by:1. Priority (High/Medium/Low)2. Component (Frontend/Backend/Infrastructure)3. Team (Team A/Team B)Within each group, sort by:- Activity date (newest first)- Impact level

Optional Data Sources

You can also include optional data sources in your custom reports. By default, CodeRabbit will not include the following data sources. In a custom report you will see the option to include these data sources by clicking the Select Optional Data Sources button. This adds special XML tags to your prompt that allow you to include this data in your report.

Bot Comments

Bot comments are comments made by bots and CodeRabbit AI on a PR. To enable bot comments you must include the tag <include_bot_comments> in your prompt. These are very similar in structure to regular user comments but with a few key differences:

<bot_comments>: array of comment objects - Contains all the comments made on the PR.
<bot_comment>: object - Each individual comment is wrapped in this tag and is an object with the following properties:
- <bot_name>: string - The username of the comment author.
- <bot_comment_created_at>: datetime - The date and time the comment was created.
- <bot_comment_updated_at>: datetime - The date and time the comment was last updated.
- <bot_comment_body>: markdown - The content of the comment.

Issues and Tickets

Issues and tickets brings in conversations, descriptions, and comments from Jira and Linear as part of your report if the ticket is linked in your PR description. To enable issues and tickets you must include the tag <include_issues_and_tickets> in your prompt.

<issues_and_tickets>: array of issue objects - Contains all the linked issues and tickets.
<issue>: object - Each individual issue is wrapped in this tag and is an object with the following properties:
- <issue_title>: string - The title or thread ID of the issue.
- <issue_url>: string - The URL to the issue.
- <issue_id>: string - The unique identifier of the issue.
- <issue_author>: string - The username of who created the issue.
- <issue_created_at>: datetime - The date and time the issue was created.
- <issue_updated_at>: datetime - The date and time the issue was last updated.
- <issue_body>: markdown - The content/description of the issue. This contains the following sections:
  - <issue_description>: markdown - The description of the issue.
  - <issue_comments>: array of comment objects - Contains all the comments made on the issue.

Remove PRs without a “Score Card/Chart” bot comment

This option gives you the ability to create a report limited only to pull requests containing a “Score Card” or “Score Chart” bot comment from CodeRabbit or other bots. To enable issues and tickets you must include the tag <pr_score_card> in your prompt.

IMPORTANT: This will automatically remove any pull requests from your reports if they do not contain a “Score Card” or “Score Chart” bot comment. Using this option without setting up a flow to create these comments will result in No new pull request activity in the last XYZ hours errors. Do not enable this option unless you have asked CodeRabbit to create a “Score Card” through a comment or implemented the “Score Chart” bot comment flow below.

For example, you can ask CodeRabbit to check several conditions on a pull request and produce a “Score Chart”:

Click to view example User Score Card/Chart Comment:

Score Card/Chart Trigger Comment Example

@coderabbitai
Use the <overall_instructions> to guide the content of the summary. Use the format shown in <\_example> but do not include or refer to the example's content in the final summary/report.

<overall_instructions>

**Instructions:**
Generate a weekly code review report for the author of this pull request only following scoring parameters. Calculate the scores and compile the results into a table so that the team-wise average score can be easily determined.
**Scoring Parameters:**

1. **Basic Code Standards (Score out of 2)**
   - Avoidance of hard-coded values
   - No repetition of code (DRY principle)

2. **Code Readability (Score out of 2)**
   - Presence of meaningful comments
   - Proper variable declaration using `const` and `let`

3. **Error Handling (Score out of 4)**
   - Handling failure scenarios (e.g., try-catch, fallbacks)
   - Proper loading state implementation (e.g., button click loading states)
   - Handling edge cases (e.g., checking for undefined or missing values)
   - Input validation (ensuring correct user inputs)

4. **Circle CI Check Validation (Score: 0 or 1)**
   - `0` → Not Passed
   - `1` → Passed

**Final Score Calculation:**
Combine the scores from the parameters above to derive the final code quality score (out of 9).
**Output Format:**
Provide the final report in a table format with the following columns (use shorthand notations), be sure to include this list at the top above the chart in the "Column Notation" section so users understand what the columns mean:

- **User Name (User)**
- **Basic Code Standards (BCS) (out of 2)**
- **Code Readability (CR) (out of 2)**
- **Error Handling (EH) (out of 4)**
- **Shopify Theme Check (CI) (out of 1)**
- **Final Code Quality Score (FCQS) (out of 9)**

</overall_instructions>

<\_example>

## Column Notation

- **User Name (User)**
- **Basic Code Standards (BCS) (out of 2)**
- **Code Readability (CR) (out of 2)**
- **Error Handling (EH) (out of 4)**
- **Shopify Theme Check (CI) (out of 1)**
- **Final Code Quality Score (FCQS) (out of 9)**

## Score Chart

| User | BCS (2) | CR (3) | EH (2) | CI (1) | FCQS (9) |
| --- | --- | --- | --- | --- | --- |
| John Doe | 2       | 3      | 2      | 1      | 9        |

</\_example>

Then CodeRabbit will reply with a score for you pull request:

Click to view resulting Score Card/Chart bot comment:

CodeRabbit Score Card/Chart Result Comment
Example

You can then utilize this in a report. We recommend your report looks specifically for these score cards and puts together a unified report:

Click to view example Report Prompt when using Score Card/Chart:

Prompt Example:

Use the <overall_instructions> to guide the content of the summary. Use the format shown in <example> but do not include or refer to the example's content in the final summary/report.

<overall_instructions>
**Instructions:**

Locate the score chart comment in the <bot_comments>. There will be a single comment with data on these fields:

- **User Name (User)**
- **Basic Code Standards (BCS) (out of 2)**
- **Code Readability (CR) (out of 2)**
- **Error Handling (EH) (out of 4)**
- **Shopify Theme Check (CI) (out of 1)**
- **Final Code Quality Score (FCQS) (out of 9)**

These details may also be in the form of a chart such as:

## Score Chart

| User | BCS (2) | CR (3) | EH (2) | CI (1) | FCQS (9) |
| --- | --- | --- | --- | --- | --- |
| John Doe | 2       | 3      | 2      | 1      | 9        |

You will create a new chart averaging all the values from various pull requests for each author. Only include pull requests with a `Score Chart`. Do not invent or create score charts if none exist.

</overall_instructions>

<example>

## Column Notation

- **User Name (User)**
- **Basic Code Standards (BCS) (out of 2)**
- **Code Readability (CR) (out of 2)**
- **Error Handling (EH) (out of 4)**
- **Shopify Theme Check (CI) (out of 1)**
- **Final Code Quality Score (FCQS) (out of 9)**

## Score Chart

| User | BCS (2) | CR (3) | EH (2) | CI (1) | FCQS (9) | PR URL |
| --- | --- | --- | --- | --- | --- | --- |
| John Doe | 2       | 3      | 2      | 1      | 9        | URL    |
| Alex Foo | 2       | 3      | 2      | 1      | 9        | URL    |

</example>
<include_bot_comments>
<pr_score_card>

Best Practices for Score Cards/Charts:

The reporting bot only has access to your comments and summary (like a project manager) if you want to make a report looking for these score card/chart comments make sure the reviewer does this ahead of time.
Only include checks for very specific scenarios, such as a specific check failing or using tabs vs spaces.
Do not use general rules without explaining specifically what they mean. If you add “Ensure the pull request follows development best practices” you must define what “development best practices” actually mean or the AI will guess.
Make one point for each specific check and make sure it’s a True/False condition.
Instead of manually commenting on pull requests, you can use the GitHub Actions Bot to automatically comment on pull requests and trigger CodeRabbit score card/chart comments by including @coderabbitai in the comment.

Organization Statistics

Organization statistics provide comprehensive organization-level metrics that can be included in custom reports. This data is very similar to what you’ll find in your CodeRabbit dashboards - if you want dashboard data in your reports, use this option! To enable organization statistics, you must include the tag <include_org_stats> in your prompt. The <organization_stats> block contains comprehensive organization-level metrics including individual PR details and high-level organization metrics, providing a complete picture of development activity and CodeRabbit’s impact across your organization. Example Prompt:

Use the <overall_instructions> to guide the content of the summary.

<overall_instructions>
Share all Organization Statistics details you find inside the <organization_stats> block.

Make the formatting of this report cool and draw some conclusions from this.

Show the top 10 tool findings and top 10 contributor info.

Use bullet points not numbers for the tool findings.

For contributors format information in a table like:

## Column Notation

- User Name: User
- PRs Created: PRC
- Reviews Approved: RA
- Reviews Requested Changes On: RRC
- Reviews Commented On: RC
- Total Comments Posted: TCP
- CodeRabbit Reviews Triggered: CRT
- Total PRs Reviewed: TPRR

## 👥 All Contributors

| User | PRC | RA | RRC | RC | TCP | CRT | TPRR |
| --- | --- | --- | --- | --- | --- | --- | --- |
| John Doe |     2 |    1 |     9 |    0 |     3 |     2 |      3 |
| Alex Foo |     2 |    1 |     9 |    1 |     3 |     2 |      1 |
</overall_instructions>

<include_org_stats>

Available Organization Statistics Data:

📊 Basic Organization Information

Organization Name: The organization’s display name
Members: Total member count
Active Repositories: Number of repositories with activity in the time period
Total Reviews: Total number of reviews performed in the time period
Total PRs: Total number of pull requests in the time period
Report Period: Start and end dates for the reporting period
Last Activity: Most recent activity date (if available)

🤖 CodeRabbit Suggestions (when > 0)

Total Suggestions: All CodeRabbit suggestions made
Potential Issues: Issues identified by CodeRabbit
Issues Found: Confirmed issues found
Refactor Suggestions: Code refactoring recommendations
Nitpick Suggestions: Minor improvement suggestions (will be 0 unless assertive/nitpick mode is enabled)

🔧 Tool Findings (when > 0)

Total Findings: All tool findings across all tools
Actionable Errors: Errors that require action
All Tools: Breakdown by tool and category showing:
- Tool name and category
- Count of findings
- Percentage of total findings

🚨 Pipeline Failures (when > 0)

Total Failures: All pipeline failures detected
Errors: Critical pipeline errors

👥 Developer Performance (when available) All Contributors: A list of developers showing:

PRs Created: The number of pull requests that this developer authored during the time period
Comments: The total number of review comments (issue, refactor, and nitpick) generated by CodeRabbit for this developer’s reviews
CodeRabbit Reviews Triggered: The number of times this developer triggered CodeRabbit reviews on pull requests
Reviews Approved: The number of unique pull requests where this developer approved the changes
Reviews Requested Changes On: The number of unique pull requests where this developer requested changes
Reviews Commented On: The number of unique pull requests where this developer left comments (without approving or requesting changes)
Total PRs Reviewed: The total number of unique pull requests where this developer performed any review action (approved, requested changes, or commented)

📈 Additional Metrics

Active Users: Number of users who were active
PRs Reviewed: Total PRs that were reviewed
PRs Merged: Total PRs that were merged
Total Suggestions Accepted: CodeRabbit suggestions that were accepted
Issue Comments: Comments on potential issues
Refactor Comments: Comments on refactoring suggestions
Learnings Created: Number of learnings created
Learnings Used: Number of learnings applied
Docstrings Generated: Number of docstrings generated
Chat Sessions: Number of chat sessions

Accepted suggestions use the same criteria as dashboard acceptance-rate metrics. See How acceptance rate is calculated.

Best practices

Be specific

Clearly define what should be included/excluded, use precise language to avoid ambiguity, and specify exact metrics you want to track.

Structure matters

Start with high-level summaries, use consistent grouping patterns, and include clear section breaks for better readability.

Keep it relevant

Focus on actionable information, avoid redundant data points, and consider your audience’s specific needs and workflows.

Optimize readability

Use appropriate formatting, include visual breaks, and maintain consistent styling throughout your reports.

Use examples

Include “do this” and “don’t do this” examples, demonstrate proper formatting patterns, and show concrete use cases.

Maintain consistency

Use <overall_instructions> and <example> tag blocks to ensure consistent formatting across teams and report types.

Add Examples for Consistent Formatting

Try to use <overall_summary> and <example> tag blocks to keep consistency across reports:

Use the <overall_instructions> to guide the content of the summary. Use the format shown in <example> but do not include or refer the example's content in the final summary/report.

<overall_instructions>
Generate release notes with the following sections:

- Summary: A high-level summary of the overall change instead of specific files within 100 words.
- Changes: A bullet point list of all the significant changes made in this release.

Significant changes include new features, bug fixes, and other notable changes.
Use a single sentence for each change without headings or categorization.
Do not include changes from PRs that have not been merged.
Don't show changes that are too insignificant and don't affect the end-user.
Use a single level of bullet points for each change.
Don't add links to the PRs.
Do not add a list of pull requests.
Do not show a random release date, version, etc. if they are not known.
</overall_instructions>

<example>
## Summary
[Summary of the release]

## Changes
- [Summary of the change 1]
- [Summary of the change 2]
- [Summary of the change 3]
- ...
- [Summary of the change N]
</example>

Example Templates

Executive Summary Template

Provide a high-level overview:
1. Key metrics:
   - Total PRs merged
   - Average review time
   - Code quality scores
2. Notable achievements
3. Blocking issues
4. Resource allocation

Format:
- Use tables for metrics
- Bullet points for achievements
- Clear headers for sections

Technical Deep Dive Template

Generate a detailed technical report:
1. Code changes:
   - Architecture updates
   - API modifications
   - Database changes
2. Testing coverage
3. Performance impacts
4. Security considerations

Include:
- Links to significant PRs
- Code snippets for major changes
- Technical debt analysis

Advanced Example Templates

Heres a more advanced example of a custom report template:

Good Day Release Report

**GPT Specialization:**
This GPT specializes in summarizing software release notes and optional summary paragraphs into a consistent, clear, and concise format. The goal is to streamline the presentation of release notes, making them easy to understand for a general audience. It prioritizes clarity, brevity, and coherence while highlighting important updates without unnecessary jargon.

**Release Note Structure:**

1. **Release Notes Organization**
   The items in the release notes may not be in the desired order. It is crucial to group similar items together meaningfully. Review the list after the release notes are created and reorder items within each heading based on relevance. Use **PRODUCT FEATURE GROUPS** to understand which items are related.

2. **General Release Note Guidelines**
   - The title should be: `GoodDay Release v${versionNumber}`

3. **Release Note Line Items**
   - Reword individual release lines to maintain a consistent tone (happy and fun)
   - Use past tense for descriptions
   - Items in the 🧼 Fixes group should begin with "Fixed"
   - Consolidate duplicate or closely related items, and list the associated GitHub pull requests as a comma-delimited list at the end (e.g., GH-123, GH-456)
   - Add links to Github App for each PR

4. **GitHub App Links**
   - each pr mentioned should include hyperlinking to the pull request such as [your-org/your-repo/pull/123](https://github.com/your-org/your-repo/pull/123)

5. **Grouping Release Note Line Items**
   - Replace any emoji in the provided content with the appropriate **RELEASE NOTE GROUP**
   - Order the **RELEASE NOTE GROUP** according to the structure below

6. **Release Note Groups**
   - 🚀 **Features**: New capabilities or enhancements
   - 🧼 **Fixes**: Bug fixes or problem resolutions
   - 🧰 **Maintenance**: Documentation, cleanup, or technical changes
   - 📚 **Other**: Anything else

7. **PR Label Uses**
   - Omit any PRs with the label `skip-changelog`
   - Use the labels from related pull requests to group items together
   - Map PR labels to release note groups using the table below:

     | RELEASE NOTE GROUP | LABELS |
     | --- | --- |
     | 🚀 Features | feature, enhancement |
     | 🧼 Fixes | bug, fix |
     | 🧰 Maintenance | design, docs |
     | 📚 Other | other, tech |

8. **Final Checks**
   - Verify that the number of items matches the number of PRs included
   - Ensure the PR links match the PR number and reflect the content of the changes

Nato’s Special Report

Generate a report of all pull requests in the following format:

- As the first paragraph, start with "🟣" if merged, "⚫" if draft, "🟢" if open, "🔴" if closed
  - On the same line, add the PR title in bold (and only the title; don't put anything else in bold after that)
  - On the same line, add the PR browser link (do not use an api link)
  - On the same line, add the last activity date in the format "Day Month Year, Hour:Minute AM/PM (Timezone)" in italic (don't put anything else in italic after that and make sure it's not bold)
- Make a new bullet-point list of high-level changes in the PR
  - Start each change with a gitmoji followed by a very terse one-liner to mention at a high level what the change does and to what part of the application it applies to
  - Do not start with verbose non-speak such as "The pull request enhances" or "This PR introduces". Keep it terse and straight to the point. Start change descriptions with a verb
  - Do not end with justifications or reasons for the changes such as "... enhancing type safety". Stick to the facts, do not make up the outcome of a change
  - Limit to the 4 most relevant changes
  - Examples: "✨ Add a rotating tagline on the home page", "🔧 Add func-style to ESLint", "📝 Add download badge to `README.md`", "✅ Add unit tests for comment trees", "👷 Create a pipeline to publish to npmjs.org", "🐛 Fix comment submission in posts", "📄 License under AGPL-3.0-or-later", "📱 Change post view for mobile", "💄 Make sidebar links blue", "🩹 Fix unfollow button", "🔒️ Limit login cookies to a specific subdomain", "🥅 Handle errors when commenting in a post", "🙈 Stop ignoring `.env` and start ignoring `.env.local` and `.env.*.local`", "⬆️ Update lemmy-js-client to v0.19.4", "🏷️ Define interfaces for pull request events", "🔐 Add environment variables for Bitbucket Server", "🚚 Rename exported client instances in test files", "🏷️ Add type alias `EventKey` and its type guard `isEventKey`", "🏗️ Aggregate exports for pull request events in an index file"
- Start the next paragraph with "Blockers:" in bold
  - Summarize any issues preventing the PR from progressing
    - Some examples: "Waiting for merge", "Waiting for review", "Failing CI/CD", "Needs more tests", "Needs rebase", "@username is waiting for a response", etc.
  - If the PR is stale, note it here
- Do not add a "Report" heading
- Make sure there is one empty line between each paragraph

These are the available emojis and the type of change they represent. Do not using any other emoji. Make sure the change corresponds to the gitmoji.

<gitmojis>
🎨: Improve structure / format of the code.
⚡️: Improve performance.
🔥: Remove code or files.
🐛: Fix a bug.
🚑️: Critical hotfix.
✨: Introduce new features.
📝: Add or update documentation.
🚀: Deploy stuff.
💄: Add or update the UI and style files.
🎉: Begin a project.
✅: Add, update, or pass tests.
🔒️: Fix security or privacy issues.
🔐: Add or update secrets.
🔖: Release / Version tags.
🚨: Fix compiler / linter warnings.
🚧: Work in progress.
💚: Fix CI Build.
⬇️: Downgrade dependencies.
⬆️: Upgrade dependencies.
📌: Pin dependencies to specific versions.
👷: Add or update CI build system.
📈: Add or update analytics or track code.
♻️: Refactor code.
➕: Add a dependency.
➖: Remove a dependency.
🔧: Add or update configuration files.
🔨: Add or update development scripts.
🌐: Internationalization and localization.
✏️: Fix typos.
💩: Write bad code that needs to be improved.
⏪️: Revert changes.
🔀: Merge branches.
📦️: Add or update compiled files or packages.
👽️: Update code due to external API changes.
🚚: Move or rename resources (e.g.: files, paths, routes).
📄: Add or update license.
💥: Introduce breaking changes.
🍱: Add or update assets.
♿️: Improve accessibility.
💡: Add or update comments in source code.
🍻: Write code drunkenly.
💬: Add or update text and literals.
🗃️: Perform database related changes.
🔊: Add or update logs.
🔇: Remove logs.
👥: Add or update contributor(s).
🚸: Improve user experience / usability.
🏗️: Make architectural changes.
📱: Work on responsive design.
🤡: Mock things.
🥚: Add or update an easter egg.
🙈: Add or update a .gitignore file.
📸: Add or update snapshots.
⚗️: Perform experiments.
🔍️: Improve SEO.
🏷️: Add or update types.
🌱: Add or update seed files.
🚩: Add, update, or remove feature flags.
🥅: Catch errors.
💫: Add or update animations and transitions.
🗑️: Deprecate code that needs to be cleaned up.
🛂: Work on code related to authorization, roles and permissions.
🩹: Simple fix for a non-critical issue.
🧐: Data exploration/inspection.
⚰️: Remove dead code.
🧪: Add a failing test.
👔: Add or update business logic.
🩺: Add or update healthcheck.
🧱: Infrastructure related changes.
🧑‍💻: Improve developer experience.
💸: Add sponsorships or money related infrastructure.
🧵: Add or update code related to multithreading or concurrency.
🦺: Add or update code related to validation.
</gitmojis>

For large reporting windows, custom reports may omit some high-cost data or fail if the prompt becomes too large. When a report includes more than 200 pull requests, CodeRabbit skips linked issues/tickets and GitHub CI/CD checks for that run. If your report still exceeds the model context limit, narrow the date range, reduce the repository or team scope, use the GROUP_BY option to split the report into smaller sections, or remove optional data sources.

​What you can customize

Content & data

Format & structure

Filtering & sorting

Language support

​Creating Custom Report Templates

​Basic Structure

​Example for different languages

​Available Data Points

​Pull Request Status

​Basic Information

​Summarized PR Details

​Comments

​CI/CD Check Status

​Formatting options

Text formatting

Lists & tables

Links & blocks

​Headers and Titles

​Language Support

​Advanced Features

​Filtering

​Custom Grouping

​Optional Data Sources

​Bot Comments

​Issues and Tickets

​Remove PRs without a “Score Card/Chart” bot comment

​Organization Statistics

​📊 Basic Organization Information

​📈 Additional Metrics

​Best practices

Be specific

Structure matters

Keep it relevant

Optimize readability

Use examples

Maintain consistency

​Add Examples for Consistent Formatting

​Example Templates

​Executive Summary Template

​Technical Deep Dive Template

​Advanced Example Templates

​Good Day Release Report

​Nato’s Special Report

​Related Resources

What you can customize

Creating Custom Report Templates

Basic Structure

Example for different languages

Available Data Points

Pull Request Status

Basic Information

Summarized PR Details

Comments

CI/CD Check Status

Formatting options

Headers and Titles

Language Support

Advanced Features

Filtering

Custom Grouping

Optional Data Sources

Bot Comments

Issues and Tickets

Remove PRs without a “Score Card/Chart” bot comment

Organization Statistics

📊 Basic Organization Information

📈 Additional Metrics

Best practices

Add Examples for Consistent Formatting

Example Templates

Executive Summary Template

Technical Deep Dive Template

Advanced Example Templates

Good Day Release Report

Nato’s Special Report

Related Resources