Feature Request: Add self-managed code review rules

[hhhsummer6967]

Describe the feature

The current code review rules are Amazon Q's defaults. We hope to add self-managed review rules in a file or directory in the repository that Amazon Q can use as a reference during code reviews. This would be similar to the rules functionality in Amazon Q Developer CLI.

Use Case

Different organizations have their own coding standards. Companies can set additional code review conditions based on their internal coding standards.

Proposed Solution

No response

Other Information

No response

[amonfaria]

Thank you for your feedback. We're actively working on supporting custom coding guidelines for the code review experience. We'll let you know once it is ready!

[amonfaria]

We have launched custom guideline rules support for code quality reviews. Here is more info on how to use it: https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/third-party-context-project-rules.html

Let us know what you think!

[kundertk]

@amonfaria is this self-managed review rules feature working? #15 seems to indicate this feature might not be working as expected, and has been a major source of frustration for our team.

[coffeencoke]

Hi @kundertk, sorry for the confusion and for the delay. Can you provide more details with your issue so we can attempt to reproduce?

Self-managed rules should be working correctly.

[kundertk]

Hi @kundertk, sorry for the confusion and for the delay. Can you provide more details with your issue so we can attempt to reproduce?

Self-managed rules should be working correctly.

Rules are ignored when doing pull requests as our reviews are full of positive praise flooding out actual human comments. Here is an example ruleset we have tried so that the reviews don't go off the rails. It doesn't listen to any of them making the comments from q-developer very frustrating to go through.

# QDeveloper Rules

0. **CRITICAL: NO PRAISE RESPONSES**
    - NEVER begin with "good", "great", "excellent", "nice", "well done", "looks good", "this is correct"
    - NEVER use positive adjectives to describe code or approaches
    - Start directly with technical feedback or "I see" / "This code"

0.1. **CRITICAL: NO ARGUING WITH DEVELOPER**
    - NEVER "respectfully disagree" or argue unless you have hard evidence (documentation, specs, test failures)
    - Accept developer decisions and provide factual information only
    - If uncertain, state "I don't have evidence to contradict this approach"
    - Only challenge with concrete proof, not opinions or preferences

1. **Be Clear and Concise**  
    - State rules and instructions directly.
    - Avoid unnecessary commentary or filler.

2. **No Hypothetical Issues**  
    - Do not invent problems or scenarios beyond provided business rules.

3. **No Praise or Positive Adjectives**  
    - NEVER start responses with "good", "great", "excellent", "nice", "well done", or similar praise
    - Do not include subjective comments, compliments, or positive evaluations
    - Skip all flattery and respond directly to technical issues

[kundertk]

something changed very recently where the github review does appear to know about these rules now. so it is possible this is fixed now?

[amonfaria]

@kundertk Thanks for flagging this — really helpful context. The capability you’re referring to (custom rules) originally launched for applying styling and guideline rules during code generation. We identified a bug that prevented some rules from being applied correctly during the /q dev review flow, and we’re actively working on addressing it.

Separately, based on feedback around verbosity and excessive praise, we also shipped updates to improve the tone and clarity of Amazon Q’s review summaries. You should now see more concise, actionable feedback and fewer unnecessary positive comments.