Join the Rovo Dev Code Standards beta

[Ryan Jiang]

Code Standards is available through a limited beta. To try it, register your interest. We will respond as soon as we receive your request.

We are opening the beta for Code Quality Standards in Rovo Dev Code Reviewer.

Define an engineering standard once, apply it to the right repositories, and see whether teams resolve the violations that Rovo Dev Code Reviewer identifies.

Engineering organizations often have important guidance for security, accessibility, APIs, testing, logging, observability, and approved frameworks. The hard part is making that guidance discoverable and consistently actionable across many repositories.

Rovo Dev Code Standards turns that written guidance into focused feedback during pull request review, with centralized administration and outcome visibility. It's already adopted widely in Atlassian teams.

What can you do with Standards?

• Create and manage organisational level standards in a central panel.
• Give developers standards-labeled feedback directly on pull request changes.
• Track violations, resolution rates, repository trends, and the pull requests where a standard produced feedback.
• Update the centrally managed standard once and keep mapped repositories aligned.

Good example use cases

• API design: Naming, versioning, backward compatibility, pagination, error response, and deprecation rules.
• Security: Input validation, secrets handling, auth checks, permission boundaries, and unsafe defaults.

• Platform conventions: Logging, metrics, error handling, dependency rules, rollout patterns, and migration requirements.

• Accessibility: Common UI rules, semantic markup, keyboard behavior, labels, and contrast expectations.

Join the beta

1. Open the Rovo Dev beta portal.

2. Register your interest in the Code Quality Standards beta.

3. Our team will review the request and respond as soon as possible with next steps.

The beta is best suited to platform teams, engineering leaders, tech leads, and Rovo Dev administrators who own standards across multiple repositories and are willing to test standards on real pull requests.

By agreeing to enter our beta program, you have to:

1. Have an active Rovo Dev license;

2. Actively using Rovo Dev Code Review;

3. Agree to share feedback and fill out surveys regularly;

All standard-related usage will be free during beta, whilst other charges remain the same. We are committed to let your team know at least 1 month before beta concludes.

---

How to get started?

Configure your first standard

1. After your beta access is enabled, open the app switcher and select Rovo Dev.

2. Open the Standards tab.

3. Choose Add Standard or start from a template.

4. Add a unique name and a short description that clearly states when Reviewer should use the standard.

5. Write focused rules in Markdown. Explain what to inspect, what a violation looks like, why it matters, and what remediation to recommend.

6. Map the standard to repositories. Start with manual selection for early validation, then expand with repository criteria when the quality is proven.

7. Save the standard and test it against pull requests containing both compliant code and intended violations.

After setting up standards, PRs in the associated repositories will be scanned against standards if the changes are relevant. You can view metrics like resolution rate and number of violations flagged by viewing the standard details. 

How to use it well?

Write standards that perform well

• Use description: The description tells the agent what standard covers and when to apply it, (e.g., "Use this to enforce best practices during Golang pull request reviews."), like registering an Agent Skill. So having a concise, well‑written description is crucial.

• Be precise: Name the language, framework, component, file type, or change pattern where the standard applies.

• Keep one clear purpose: Split broad standards into focused checks when possible.

• Describe failure and remediation: Tell Reviewer what bad code looks like and what useful feedback should ask the developer to change.

• Include non-goals: State what Reviewer should ignore so comments remain focused.

• Use concise examples: Add short allowed and disallowed patterns when natural-language guidance may be ambiguous.

• Iterate using real reviews: Use false positives, misses, and resolution behavior to improve the standard.

Common mistakes

• Copying a whole policy doc: Long docs dilute attention. Extract the enforceable parts.
• Skipping the description: A vague description makes routing worse.
• Mixing unrelated topics: Split security, testing, API, and style concerns into separate standards will help.
• Leaving out exceptions: Missing exceptions create false positives.
• Writing aspirations instead of checks: “Write clean code” is not enforceable. “Use the shared error response shape for public REST endpoints” is enforceable.
• Being overly wordy or too vague: Just like working with humans, giving them the right amount of context and guidance whilst not overwhelming them generates best results.

Examples

Weak standard:

Make sure APIs follow best practices and are easy to maintain.

This is too broad. It does not say when to apply the standard, what to inspect, what failure it prevents, or what fix to suggest.

Better standard:

Use this standard for REST API changes. Check that new public endpoints return the shared error response shape, document expected error codes, and include an integration test for at least one failure path. Do not flag internal-only endpoints or endpoints behind the temporary migration flag rest_error_v2_migration. If missing, ask for the smallest change that adds the shared error response and a failure-path test.

This is easier for Reviewer to apply because it has scope, checks, exceptions, and an expected remediation.

---

What should you expect during beta?

• Standards are selectively loaded based on their descriptions and the pull request context. A narrow standard may correctly produce comments on only a small percentage of reviews.
• A standard can improve review guidance, but it does not guarantee that every possible violation will be found.
• Standards do not currently execute shell or Python scripts.
• Large instructions compete with code context. Keep standards concise and split overlapping guidance.
• Administrators need Rovo Dev admin access to manage standards and access to the relevant repository or workspace to map them.
• The current experience is optimized for the Rovo Dev billing site rather than cross-site standards administration.
• More advanced traceability, versioning, permission, and testing workflows remain areas we are evaluating through beta feedback.

Share beta feedback

Use the Rovo Dev beta portal to report your experience or request support. For quality feedback, include the pull request, standard name, Reviewer comment, and what the correct behavior should have been. You can also use thumbs up or thumbs down on standards-related Reviewer comments when available.