Set custom instructions for code reviews
Custom instructions are only available to users on a Rovo Dev Standard plan.
The pull request author’s Rovo Dev Standard plan must be on the Jira site connected to the Bitbucket workspace or GitHub organization the pull request is created in.
Use custom instructions to tailor the feedback Rovo Dev leaves on your pull requests. Add your own team’s unique standards, patterns, and preferences so you only get the comments your team finds most useful.
Set custom instructions for a repository
Create a
.rovodevfolder in your repository root.Add a
.review-agent.mdfile in the.rovodevfolder and add clear, specific instructions for Rovo Dev to follow when reviewing pull requests in the repository.ファイルを保存する。
How to write effective custom instructions
Write custom instructions that are clear, focused, and easy for Rovo Dev to follow.
Use simple, actionable rules addressing one topic at a time.
Include concrete details like file patterns, naming conventions, or code structures.
Provide examples of both good and bad practices.
Keep formatting consistent, like using a new line and bullet point for each instruction.
Group related instructions together with categories like “Code quality”, “Architecture”, or “QA”.
Mention topics to ignore, such as formatting issues handled by linters.
Avoid adding too many instructions to begin. Start small and add incrementally to test the effect your instructions have.
Examples of custom instructions
You can use custom instructions to teach Rovo Dev your team’s custom standards, so it can make more specific, targeted suggestions.
These are examples of successful custom instructions so you can write your own for your team.
To specify code review guidelines to enforce coding standards:
# Code Review Guidelines: Anti-Patterns and Better Solutions
## Code Quality & Structure
### Naming Conventions
**When you spot unclear or abbreviated variable names**, you should **suggest the author use descriptive, meaningful names that follow camelCase convention** instead of abbreviations or generic names.
### Code Organization
**When you spot functions exceeding 50 lines**, you should **suggest the author break them into smaller, single-purpose functions** instead of having one large function.
**When you spot nested conditional statements exceeding 3 levels**, you should **suggest the author use early returns and guard clauses** instead of deep nesting.
### Error Handling
**When you spot empty catch blocks or silent error suppression**, you should **suggest the author implement proper error logging with context** instead of ignoring errors.
**When you spot generic Error objects being thrown**, you should **suggest the author create specific error classes with meaningful messages** instead of using generic errors.
### Performance Standards
**When you spot expensive operations inside loops**, you should **suggest the author move calculations outside loops or use array methods** instead of recalculating values repeatedly.
**When you spot missing cleanup in useEffect hooks**, you should **suggest the author add cleanup functions for event listeners and subscriptions** instead of leaving resources attached.
## Architecture & Design
### Design Patterns
**When you spot classes or functions with multiple responsibilities (God Object anti-pattern)**, you should **suggest the author separate concerns into focused, single-purpose modules** instead of having one module handle everything.
### API Design
**When you spot inconsistent API response structures**, you should **suggest the author use a standardized response format** instead of different structures for different endpoints.
**When you spot missing input validation**, you should **suggest the author implement proper validation schema** instead of trusting user input.
### Security Standards
**When you don't sanitize user input**, you should **validate and sanitize all inputs** instead of trusting user data.
## Quality Assurance
### Monitoring & Observability
**When you use console.log for debugging**, you should **implement proper logging with levels and context** instead of cluttering code with console statements.
---
# Review topics to exclude
Below are the topics you should avoid from commenting in your code reviews.
## Avoid providing feedback on formatting
**When you find non-critical code formatting issues**, you should **avoid leaving any suggestions** because we have linter rules in place to cover these issues.
## Avoid providing feedback on inline comments
**When you find inline code comments**, you should **avoid leaving any suggestions regarding its validity, content or formatting** because inline comments are NOT in scope for code reviewsTo enforce structured logging for high cardinality values:
#Logging
KotlinLogging is the preferred logging library. Avoid using println for logging purposes.
Use structured logging to separate log values from messages:
logger.atInfo {
message = "User logged in"
payload = mapOf("userId" to user.id)
}To enforce feature gating of risky changes:
# Feature Gate
Confirm changes to existing code are feature gated using the utils/FeatureService.kt and tested on and off.
Minor changes such a non-intrusive, self-contained and inactive changes do not require feature gates.Or, to warn about specific kinds of security risks:
Look at the files names in the commit. This analysis applies to Poco policy files which describe authorization rules and generally named `policy*.json`.
The content of the file will be similar to:
Example 1:
```
{
"allow": [
{
"description": "allow unauthenticated requests through the global edge",
"methods": [
"GET"
],
"paths": [
"/api/some/path"
],
"principals": {
"asap": {
"issuers": [
"micros/edge-authenticator"
]
}
},
"runtime": {}
}
]
}
```
Example 2:
```
{
"allow": [
{
"description": "Allow access to /handle",
"paths": [
"/handle"
],
"methods": ["POST"],
"principals": {
"open": {
}
}
}
]
}
```
In this case path require proper authorization and are not public.
Example 3:
```
{
"description": "Allow only authenticated services to our activate/cancel endpoint",
"paths": ["/entitlements/activate",
"/entitlements/cancel"],
"methods": ["GET"],
"principals": {
"asap": {
"issuers": [
"micros/marketplace-demand-service",
"micros/marketplace-amkt-fe-server",
"micros/sandbox-service",
"micros/enterprise-gatekeeper",
"micros/id-org-manager",
"pollinator-check/d3f187a2-2b22-4554-8795-559f707fc1f3",
"pollinator-check/fd9a2908-7d2f-4a76-965e-121bec464e9b",
"micros/cosmos"
]
},
"staff": {
"groups": [
"micros-sv--pls-orchestration-adapter-dl-admins"
]
}
},
```
In order to be publicly accessible, poco policy usually need to have corresponding path opened to public in the service descriptor file named `service-descriptor.yml`
If poco policy is properly secured and service descriptor has path opened, resulting policy may not be public.
In example below has /api/some/path opened to public in the service descriptor file:
```
resources:
- type: globaledge
name: internet
attributes:
routes:
- match:
prefix: '/api/some/path'
ip_whitelist:
- public
```
Warn when a path is open publicly in `service-descriptor.yml`.
Warn when a poco policy is not properly secured.You can also tell Rovo Dev specific details about your codebase (like frameworks and versions) so it can avoid making irrelevant suggestions:
# UI Components
The Flex component is a basic mapping to the CSS Flexbox API. It can be used as a less richly-configured Inline or Stack.
Like Stack and Inline, Flex exclusively supports token-backed gap properties to ensure layouts using Flex match the Atlassian Design System spacing scale.
Props: justifyContent, alignItems, wrap, direction
# Atlassian Design System Spacing
The 8px base unit also forms the basis of our space token system, as the base unit space.100. Every space token is a multiple of this base unit, the number suffix representing the percentage of the base unit.
For example, space.200 is 200% of the size of the base unit, therefore represents 16px.
Each space token should be used in place of the raw pixel or REM values when adding space between components or objects on a page.この内容はお役に立ちましたか?