Set custom instructions for code reviews
This article is for Code Reviewer, currently in beta. Starting in October, Code Reviewer will become Rovo Dev code reviews and these instructions may change. Read more about the Rovo Dev rollout
Use custom instructions to tailor the code reviewer comments 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.
To set custom instructions for a repository:
Create a
.rovodev/.review-agent.mdmarkdown file in the repository root.Write clear, specific instructions for Rovo Dev to follow when reviewing pull requests in the repository.
Save the file.
Try out your new instructions with a few sample pull requests, and easily refine them as you go based on your results or feedback from your team.
We suggest you start with a few important instructions and, when you’re happy with how they’re working, expand the list of instructions gradually.
Tips for writing custom instructions
Write clear, actionable rules as commands (e.g. "Check for...", "Ensure that..."), keeping each instruction focused on a single concern.
Keep your instruction set simple - too many instructions or conflicting instructions cause problems, and there’s no need to create instructions for what linters already check.
Include concrete details like file patterns, naming conventions, code structures, and use examples of both good and bad practices.
Use consistent formatting and terminology (e.g. each instruction on a new line with a bullet point).
Write your instructions to fit your team’s workflow - don’t slow work down with overly strict or unnecessary rules, and consider all experience levels in your team.
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.
For example, to 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.
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.Was this helpful?