This feature is available exclusively as part of the Pro plan and is not included in the Lite plan. Please refer to our pricing page for more information about our plans and features.
CodeRabbit Pro allows you to create custom reports tailored to your specific needs using a flexible prompt-based system. This guide will help you understand how to create effective custom reports. For a conceptual overview of reports in CodeRabbit, see Generate reports.

​
Understanding Custom Reports​

Custom reports allow you to:
  • Define exactly what information you want to see
  • Specify the format and structure of the report
  • Set custom filtering and grouping rules
  • Generate reports in different languages

​
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 indidvidual 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 markdown formatting in custom reports. You can use:
  • Headers (#, ##, ###)
  • Lists (bullet points and numbered)
  • Tables
  • Code blocks
  • Bold and italic text
  • Links

​
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”:
Then CodeRabbit will reply with a score for you pull request:
You can then utilize this in a report. We recommend your report looks specifically for these score cards and puts together a unified report:
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 “Insure 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 its 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.

​
Best Practices​

  1. Be Specific
    • Clearly define what should be included/excluded
    • Use precise language to avoid ambiguity
    • Specify exact metrics you want to track
  2. Structure Matters
    • Start with high-level summaries
    • Use consistent grouping patterns
    • Include clear section breaks
  3. Keep it Relevant
    • Focus on actionable information
    • Avoid redundant data points
    • Consider your audience’s needs
  4. Optimize Readability
    • Use appropriate formatting
    • Include visual breaks
    • Maintain consistent styling
  5. Use Examples
    • Include “do this” and “don’t do this” examples (especially for titles)
    • Demonstrate proper formatting patterns
    • Show concrete use cases for different report types
    • Help maintain consistency across teams
    • Avoid ambiguity in report generation

​
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 scores2. Notable achievements3. Blocking issues4. Resource allocationFormat:- 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 changes2. Testing coverage3. Performance impacts4. Security considerationsInclude:- 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 PR4. **GitHub App Links**   - each pr mentioned should include hyperlinking to the pull request such as [coderabbitai/mono/pull/2614](https://github.com/coderabbitai/mono/pull/2614)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 below6. **Release Note Groups**   - 🚀 **Features**: New capabilities or enhancements   - 🧼 **Fixes**: Bug fixes or problem resolutions   - 🧰 **Maintenance**: Documentation, cleanup, or technical changes   - 📚 **Other**: Anything else7. **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 paragraphThese 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>
Edit this page Last updated on Jul 31, 2025