Custom Reports
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.
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
Merged
: boolean (true/false) - Whether the PR has been mergedDraft
: boolean (true/false) - Whether the PR is in draft stateState
: string ("open"/"closed") - Current state of the PRMergeable
: boolean (true/false) - Whether the PR can be mergedIs stale
: boolean - Whether PR has been inactive for over 168 hours
Basic Information
Pull request number
: number - The PR's identifierTitle
: string - PR titleURL
: string - Link to the PRAuthor name
: string - PR creator's usernameCreated at
: datetime - When the PR was createdLast activity
: datetime - Most recent activity timestampClosed at
: datetime (if applicable) - When the PR was closed
Additional Context
Labels
: array of strings - All labels applied to the PRReviewers
: array of strings - Assigned reviewers' usernamesDescription
: markdown - Full PR descriptionSummary
: string - AI-generated summary of changesComments
: array of objectsusername
: string - Comment authorbody
: markdown - Comment content
Here's an example prompt that uses these data points:
Generate a summary with the following format for each PR:
## [PR Title](URL)
**Status**: {Use these symbols based on state}
- 🔀 if Merged is true
- 📝 if Draft is true
- 💬 if State is "open"
- 🔒 if State is "closed" and not merged
Add ⚠️ if Is stale is true
**Author**: {Author name}
**Created**: {Created at}
**Labels**: {Labels joined by commas}
**Reviewers**: {Reviewers joined by commas}
### Summary
{Summary limited to 50 words}
### Recent Activity
{List last 3 comments with username and content}
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
Language Support
You can generate reports in multiple languages by specifying the ISO language code in your template. For example:
Language: fr
Please 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 developers
Exclude:
- 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
Time-Based Analysis
Add temporal analysis to your reports:
Provide:
- Week-over-week comparison
- Trend analysis for the past month
- Velocity metrics
- Time to merge statistics
Best Practices
-
Be Specific
- Clearly define what should be included/excluded
- Use precise language to avoid ambiguity
- Specify exact metrics you want to track
-
Structure Matters
- Start with high-level summaries
- Use consistent grouping patterns
- Include clear section breaks
-
Keep it Relevant
- Focus on actionable information
- Avoid redundant data points
- Consider your audience's needs
-
Optimize Readability
- Use appropriate formatting
- Include visual breaks
- Maintain consistent styling
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 Formatting
Heres a more advanced example of a custom report template:
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>