Sample prompts to customize Rovo Dev's AI code review agent

Ash Moosa

Hi everyone,

In tomorrow’s webinar Accelerate code review with Rovo Dev, one of the features we’ll demo is how you can use your organization's custom coding standards as context for the code review agent.

This will help the agent leave comments on your code that you care about and reduce the number of comments that you’re not likely to act on.

If you haven’t signed up for the webinar, sign up here, or if you miss it, you can watch the recording on the same link. We are going to do a demo and share some internal developer stories as well.

Here are the prompts that we’ll use for the demo.

1. Regulated data handling (PII/PHI/PCI)

Who is this for: orgs with strict privacy/compliance (HIPAA, PCI DSS, GDPR-heavy environments).

### Regulated data (PII/PHI/PCI)

- Flag any new code that:
- Stores or logs personally identifiable information (PII) or protected health information (PHI).
- Transmits payment card data or sensitive identifiers.
- For any such data:
- Ensure it is **never** logged in plain text (including debug logs and errors).
- Check that it is passed only through approved encryption or tokenization utilities.
- Verify that access to this data goes through our authorization checks, not direct DB access.
- If you see raw PII/PHI/PCI data being used directly in logs, errors, metrics, or external calls:
- Raise a comment describing the risk.
- Suggest using our approved redaction and masking helpers (e.g., `mask_ssn`, `mask_email`).

 

2. Multi-tenant SaaS isolation rules

Who is this for: SaaS vendors with strict tenant isolation, especially enterprise B2B.

 

<span data-testid="renderer-code-block-line-1" data-ds--code--row="">### Tenant isolation
</span><span data-testid="renderer-code-block-line-3" data-ds--code--row="">- Treat `tenant_id` as a required parameter in all multi-tenant code paths:
</span><span data-testid="renderer-code-block-line-4" data-ds--code--row="">  - Flag any DB query, cache access, or API call that does not filter or scope by `tenant_id` where it should.
</span><span data-testid="renderer-code-block-line-5" data-ds--code--row="">- Prevent cross-tenant data access:
</span><span data-testid="renderer-code-block-line-6" data-ds--code--row="">  - If code joins or mixes data sets, ensure they are consistently scoped to the same `tenant_id`.
</span><span data-testid="renderer-code-block-line-7" data-ds--code--row="">  - Highlight any use of "global" queries that could accidentally return multiple tenants' data.
</span><span data-testid="renderer-code-block-line-8" data-ds--code--row="">- For background jobs and batch processes:
</span><span data-testid="renderer-code-block-line-9" data-ds--code--row="">  - Verify that each job run is clearly associated with a tenant or an explicitly defined multi-tenant-safe operation.
</span><span data-testid="renderer-code-block-line-10" data-ds--code--row="">- If unsure whether an operation should be tenant-scoped, comment and ask the author to confirm the intended behavior.</span>

 

3. Feature

Who is this for: Teams doing lots of A/B testing, gradual rollouts, or dark launches.

### Feature flags and experiments

- For new user-facing features:
- Check that the behavior is guarded by a feature flag or configuration, not hard-coded.
- Verify that there is a clearly defined "off" path (kill-switch) that restores previous behavior.
- For experiment code:
- Ensure that experiment variants are clearly named and do not leak into core logic.
- Flag persistent branching on experiment IDs in core domain code; suggest isolating it behind an abstraction.
- For deprecated flags:
- Warn if code references feature flags marked as "to be removed" or "expired" in comments or config.

4. Observability and incident response standards

Who is this for: SRE-heavy orgs, or teams with strict production SLOs and on-call rotations.

### Logging, metrics, and tracing
- For new critical paths (auth, payments, provisioning, data writes):
- Check that appropriate structured logs are emitted with correlation IDs (e.g., `request_id`, `user_id`, `tenant_id`).
- Verify that errors are logged at the correct severity and include enough context to debug without exposing secrets.
- Ensure new endpoints or background jobs:
- Emit metrics for success/failure counts and latency, using our standard metrics library.
- Attach tracing information if our tracing framework is in use (e.g., `start_span`, `add_attribute`).
- Flag:
- `console.log`-style debugging left in production code.
- Silent catch blocks that swallow errors without logging or metrics.

5. Domain-specific business rules (e.g., finance, marketplaces)

Who is this for: Organizations with sensitive domain logic: finance, inventory, pricing, risk, marketplaces, etc.

### Domain-specific business rules
- For code affecting prices, balances, or financial calculations:
- Check that it uses our approved money types and rounding utilities, not raw floats.
- Verify that any currency conversion uses our central FX service or library.
- For code affecting orders, inventory, or fulfillment:
- Ensure state transitions follow our defined lifecycle (see `OrderState` and `OrderStateDiagram.md`).
- Flag direct state mutations that skip required validation or side-effect handlers.
- When you see new business rules:
- Check if they are duplicated from another module; recommend consolidating to a shared domain service where appropriate.
- Highlight any rule that contradicts or bypasses an existing documented rule in `BusinessRules.md`.

6. Legacy migration and strangler patterns

Who is this for: Orgs mid-migration from a monolith to microservices, or from one platform to another (e.g., v1 → v2 APIs).

### Legacy system migration
- Encourage the strangler pattern:
- Flag new dependencies on legacy modules tagged as `@legacy` or in the `legacy/` directory.
- Suggest implementing new functionality in the `v2` or `new-architecture` modules instead.
- For code touching migration boundaries:
- Verify that adapters or facades are used rather than direct calls across old/new boundaries.
- Ensure new code does not introduce bidirectional dependencies between legacy and new modules.
- If new code extends deprecated APIs:
- Ask why it is not implemented using the new APIs.
- Recommend migration steps or references from `MigrationGuide.md`.

7. UI/UX and design system adherence

Who is this for: Product teams with a formal design system or strict accessibility standards.

### Design system and accessibility
- For frontend components:
- Check that they use our official design system components (e.g., `Button`, `Modal`, `TextField`) instead of custom elements.
- Flag inline styles or ad-hoc components that duplicate design system patterns.
- Accessibility:
- Ensure interactive elements (buttons, links, inputs) have accessible labels (`aria-label`, `alt`, etc.).
- Warn about patterns that typically break accessibility (click handlers on non-interactive elements, missing focus states).
- Theming:
- Verify color usage comes from our theme tokens, not hard-coded hex values, especially for text and backgrounds.

8. Cloud and infrastructure governance

Who is this for: Cloud-native orgs with strong infra/security governance (e.g., AWS/Azure/GCP shops).

### Cloud and infrastructure policies
- For infrastructure-as-code (e.g., Terraform, CloudFormation, Kubernetes manifests):
- Check that resources include required tags/labels (`team`, `env`, `owner`, `cost-center`).
- Flag public-facing resources (load balancers, storage buckets, security groups) that do not use our approved modules.
- For storage:
- Warn if buckets or storage accounts are configured as public or world-readable unless explicitly tagged as allowed.
- Ensure that encryption-at-rest and in-transit settings follow our defaults.
- For network access:
- Highlight any new wide-open firewall rules (e.g., `0.0.0.0/0`) that do not reference our standard security groups.

9. Open source and licensing policies

Who is this for: Enterprises with legal/compliance constraints on OSS usage.

### Open source dependencies and licenses
- For new dependencies:
- Check package names and metadata against our disallowed licenses list (e.g., AGPL, custom restrictive licenses).
- Flag any dependency that is not in `approved-dependencies.md`.
- For direct GitHub or raw URL imports:
- Raise a comment asking to use our internal artifact repository or vetted packages instead.
- If you see custom or unknown licenses:
- Ask the author to confirm legal approval, referencing `OSS-Policy.md`.

If you’ve tried Rovo Dev’s code review capability, please share your feedback and what other features you’d like to see us build.

Martin Runge

Hi @Ash Moosa I truly value this article, especially the detailed prompt samples. The examples surpass generic AI advice and demonstrate practical, production-ready patterns that teams can quickly incorporate into their engineering practices. I particularly appreciate how the prompts address real-world issues, such as compliance. Thank you for sharing these examples; I look forward to seeing how this develops.

Cheers, Martin