Skip to content

Add Go-specific path instructions for CodeRabbit reviews #97

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
Okd2006 wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Add Go-specific path instructions for CodeRabbit reviews #97

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
226 changes: 73 additions & 153 deletions .coderabbit.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4,88 +4,66 @@
# Language for CodeRabbit's review comments
language: en

# Enable experimental features (currently not using any specific early_access features)
# Enable experimental features
early_access: true

chat:
# CodeRabbit will automatically respond to @coderabbitai mentions in PR comments
auto_reply: true

issue_enrichment:
labeling:
auto_apply_labels: true
labeling_instructions:
- label: bug
instructions: Issues reporting bugs, errors, crashes, incorrect behavior, or unexpected results. This includes runtime errors, logic errors, broken functionality, regressions, and any deviation from expected or documented behavior.
instructions: Issues reporting bugs, crashes, incorrect behavior, regressions, or unexpected results.
- label: enhancement
instructions: Feature requests, improvements to existing functionality, performance optimizations, refactoring suggestions, UI/UX enhancements, and any suggestions to make the project better or add new capabilities.
instructions: Feature requests, improvements, optimizations, refactoring suggestions, or new capabilities.
- label: documentation
instructions: Documentation updates, additions, corrections, or clarifications needed. This includes missing docs, outdated information, unclear instructions, API documentation, code examples, README improvements, and any requests for better explanations or guides.
instructions: Documentation updates, corrections, missing docs, or README improvements.

planning:
enabled: true
auto_planning:
enabled: true
labels:
- "plan-me" # Auto-plan issues with this label
- "feature" # Also auto-plan these
- "!no-plan" # Never auto-plan issues with this label
- "plan-me"
- "feature"
- "!no-plan"

reviews:
profile: assertive # Options: chill (focuses on significant issues, less nitpicky about style), assertive (more thorough, flags style issues and minor improvements too)
profile: assertive

auto_review:
# Automatically trigger reviews when PRs are opened or updated
enabled: true
# Skip auto-review if PR title contains these keywords
ignore_title_keywords:
- "WIP"
# Don't auto-review draft PRs
drafts: false
# Only auto-review PRs targeting these branches
base_branches:
- main
- develop

# Include a high-level summary at the start of each review
high_level_summary: true

# Generate sequence diagrams for complex code flows
sequence_diagrams: true

# Include poems in reviews
poem: true

# Show review completion status
review_status: true

# Keep the walkthrough section expanded by default
collapse_walkthrough: false

# Include summary of all changed files
changed_files_summary: true

# Automatically request changes on the PR (just leave comments)
request_changes_workflow: true

# Pre-merge checks to enforce before merging PRs
pre_merge_checks:
description:
# Validate that PR has a proper description
mode: warning # Options: off, warning, error
mode: warning
docstrings:
# Disable docstring coverage checks (let's assume we don't need them)
mode: off

# Exclude these paths from reviews (build artifacts and dependencies)
path_filters:
- "!**/node_modules/**" # npm dependencies
- "!**/android/**" # Native Android build files
- "!**/ios/**" # Native iOS build files
- "!**/.expo/**" # Expo build cache
- "!**/.expo-shared/**" # Expo shared config
- "!**/dist/**" # Build output
- "!**/node_modules/**"
- "!**/android/**"
- "!**/ios/**"
- "!**/.expo/**"
- "!**/.expo-shared/**"
- "!**/dist/**"

# Use the following tools when reviewing
tools:
shellcheck:
enabled: true
Expand Down Expand Up @@ -122,159 +100,101 @@ reviews:
eslint:
enabled: true

# Apply the following labels to PRs
labeling_instructions:
- label: Python Lang
instructions: Apply when the PR/MR contains changes to python source-code
instructions: Apply when the PR contains Python source code changes
- label: Solidity Lang
instructions: Apply when the PR/MR contains changes to solidity source-code
instructions: Apply when the PR contains Solidity source code changes
- label: Typescript Lang
instructions: Apply when the PR/MR contains changes to javascript or typescript source-code
instructions: Apply when the PR contains JavaScript or TypeScript code
- label: Ergoscript Lang
instructions: Apply when the PR/MR contains changes to ergoscript source-code
instructions: Apply when the PR contains ErgoScript code
- label: Bash Lang
instructions: >-
Apply when the PR/MR contains changes to shell-scripts or BASH code
snippets
instructions: Apply when the PR contains shell scripts or Bash code
- label: Make Lang
instructions: >-
Apply when the PR/MR contains changes to the file `Makefile` or makefile
code snippets
instructions: Apply when the PR modifies Makefile
- label: Documentation
instructions: >-
Apply whenever project documentation (namely markdown source-code) is
updated by the PR/MR
instructions: Apply when Markdown documentation is updated
- label: Linter
instructions: >-
Apply when the purpose of the PR/MR is related to fixing the feedback
from a linter
instructions: Apply when PR fixes linter feedback

# Review instructions that apply to all files
instructions: >-
- Verify that documentation and comments are free of spelling mistakes
- Ensure that test code is automated, comprehensive, and follows testing best practices
- Verify that all critical functionality is covered by tests
- Confirm that the code meets the project's requirements and objectives
- Confirm that copyright years are up-to date whenever a file is changed
- Point out redundant obvious comments that do not add clarity to the code
- Ensure that comments are concise and suggest more concise comment statements if possible
- Discourage usage of verbose comment styles such as NatSpec
- Look for code duplication
- Suggest code completions when:
- seeing a TODO comment
- seeing a FIXME comment
- Verify documentation and comments have no spelling mistakes
- Ensure automated tests exist and are comprehensive
- Confirm critical functionality is covered by tests
- Confirm the code meets project requirements
- Ensure copyright years are updated
- Identify redundant comments
- Ensure comments remain concise
- Discourage verbose comment styles such as NatSpec
- Detect duplicated code
- Suggest improvements for TODO or FIXME comments

Comment on lines 121 to 132
Copy link
Contributor

@coderabbitai coderabbitai bot Mar 5, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

Global NatSpec discouragement conflicts with Solidity review quality.

Line 129 applies globally and can suppress useful contract documentation patterns in Solidity PRs. Scope this rule away from Solidity-targeted reviews.

Proposed config adjustment 
   instructions: >-
     - Verify documentation and comments have no spelling mistakes
     - Ensure automated tests exist and are comprehensive
     - Confirm critical functionality is covered by tests
     - Confirm the code meets project requirements
     - Ensure copyright years are updated
     - Identify redundant comments
     - Ensure comments remain concise
-    - Discourage verbose comment styles such as NatSpec
     - Detect duplicated code
     - Suggest improvements for TODO or FIXME comments
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
instructions: >-
- Verify that documentation and comments are free of spelling mistakes
- Ensure that test code is automated, comprehensive, and follows testing best practices
- Verify that all critical functionality is covered by tests
- Confirm that the code meets the project's requirements and objectives
- Confirm that copyright years are up-to date whenever a file is changed
- Point out redundant obvious comments that do not add clarity to the code
- Ensure that comments are concise and suggest more concise comment statements if possible
- Discourage usage of verbose comment styles such as NatSpec
- Look for code duplication
- Suggest code completions when:
- seeing a TODO comment
- seeing a FIXME comment
- Verify documentation and comments have no spelling mistakes
- Ensure automated tests exist and are comprehensive
- Confirm critical functionality is covered by tests
- Confirm the code meets project requirements
- Ensure copyright years are updated
- Identify redundant comments
- Ensure comments remain concise
- Discourage verbose comment styles such as NatSpec
- Detect duplicated code
- Suggest improvements for TODO or FIXME comments
instructions: >-
- Verify documentation and comments have no spelling mistakes
- Ensure automated tests exist and are comprehensive
- Confirm critical functionality is covered by tests
- Confirm the code meets project requirements
- Ensure copyright years are updated
- Identify redundant comments
- Ensure comments remain concise
- Detect duplicated code
- Suggest improvements for TODO or FIXME comments
🤖 Prompt for AI Agents 
Verify each finding against the current code and only fix it if needed.

In @.coderabbit.yaml around lines 121 - 132, The global rule under the
instructions key that currently reads "Discourage verbose comment styles such as
NatSpec" should be scoped to avoid applying to Solidity code; update the config
to exclude Solidity-targeted reviews by adding a per-language override or
file-pattern exception (e.g., allow NatSpec for files matching *.sol or
language: solidity) so the instruction does not suppress Solidity contract
documentation—locate the instructions block and the specific item "Discourage
verbose comment styles such as NatSpec" and change it to a
conditional/overridden rule for non-Solidity contexts.

# Custom review instructions for specific file patterns
path_instructions:
# TypeScript/JavaScript files

- path: "**/*.go"
instructions: |
Go code review guidelines:

**Naming & Style**
- Follow Effective Go naming conventions.
- Package names should be lowercase and descriptive.
- Exported functions and types should include godoc comments.

**Error Handling**
- Errors should not be ignored.
- Prefer wrapping errors using fmt.Errorf("...: %w", err).

**Testing**
- Prefer table-driven tests where appropriate.
- Ensure exported functions have tests when applicable.

- path: "**/*.{ts,tsx,js,jsx}"
instructions: |
NextJS:
- Ensure that "use client" is being used
- Ensure that only features that allow pure client-side rendering are used
- NextJS best practices (including file structure, API routes, and static generation methods) are used.

- Ensure "use client" is used when required
- Follow NextJS best practices

TypeScript:
- Avoid 'any', use explicit types
- Prefer 'import type' for type imports
- Review for significant deviations from Google JavaScript style guide. Minor style issues are not a priority
- The code adheres to best practices associated with React
- The code adheres to best practices associated with React PWA
- The code adheres to best practices associated with SPA
- The code adheres to best practices recommended by lighthouse or similar tools for performance
- The code adheres to best practices associated with Node.js
- The code adheres to best practices recommended for performance
- Avoid `any`
- Prefer `import type`
- Follow React and Node.js best practices

Security:
- No exposed API keys or sensitive data
- Use expo-secure-store for sensitive storage
- Validate deep linking configurations
- Check for common security vulnerabilities such as:
- SQL Injection
- XSS (Cross-Site Scripting)
- CSRF (Cross-Site Request Forgery)
- Insecure dependencies
- Sensitive data exposure
- No exposed API keys
- Check for SQL Injection, XSS, CSRF
- Avoid insecure dependencies

Internationalization:
- User-visible strings should be externalized to resource files (i18n)
- Externalize user-visible strings (i18n)

# HTML files
- path: "**/*.html"
instructions: |
Review the HTML code against the google html style guide and point out any mismatches. Ensure that:
- The code adheres to best practices recommended by lighthouse or similar tools for performance
Review HTML against Google HTML style guide.
Ensure Lighthouse performance best practices.

# CSS files
- path: "**/*.css"
instructions: |
Review the CSS code against the google css style guide and point out any mismatches. Ensure that:
- The code adheres to best practices associated with CSS.
- The code adheres to best practices recommended by lighthouse or similar tools for performance.
- The code adheres to similar naming conventions for classes, ids.
Review CSS against Google CSS style guide.
Ensure Lighthouse performance best practices.

# Python files
- path: "**/*.{py}"
- path: "**/*.py"
instructions: |
Python:
- Check for major PEP 8 violations and Python best practices.
Check major PEP8 violations and Python best practices.

# Solidity Smart Contract files
- path: "**/*.sol"
instructions: |
Solidity:
- Review the Solidity contracts for security vulnerabilities and adherence to best practices.
- Ensure immutability is used appropriately (e.g., `immutable` and `constant` where applicable).
- Ensure there are no unbounded loops that could lead to gas exhaustion.
- Verify correct and explicit visibility modifiers for all state variables and functions.
- Flag variables that are declared but used only once or are unnecessary.
- Identify potential gas optimization opportunities without compromising readability or security.
- Verify that any modification to contract logic includes corresponding updates to automated tests.
- Ensure failure paths and revert scenarios are explicitly handled and validated.
- Validate proper access control enforcement (e.g., Ownable, RBAC, role checks).
- Ensure consistent and correct event emission for all state-changing operations.
- Confirm architectural consistency with existing contracts (no unintended storage layout changes unless clearly documented).
- Flag major feature additions or architectural changes that were implemented without prior design discussion (if applicable).
- Flag pull requests that mix unrelated changes or multiple concerns in a single submission.
- Ensure security-sensitive logic changes are not introduced without adequate test coverage.
- Review for common smart contract vulnerabilities, including but not limited to:
- Reentrancy
- Improper input validation
- Access control bypass
- Integer overflows/underflows (if using unchecked blocks)
- Front-running risks where applicable
Review Solidity contracts for security vulnerabilities.
Verify access control, event emission, and storage layout consistency.


# Javascript/Typescript test files
- path: "**/*.test.{ts,tsx,js,jsx}"
instructions: |
Review test files for:
- Comprehensive coverage of component behavior
- Proper use of @testing-library/react-native
- Async behavior is properly tested
- Accessibility testing is included
- Test descriptions are sufficiently detailed to clarify the purpose of each test
- The tests are not tautological
Review test files for coverage, async behavior, and clear test descriptions.

# Solidity test files
- path: "**/*.test.{sol}"
instructions: |
Review test files for:
- Comprehensive coverage of contract behavior.
- Coverage of success paths, edge cases, and failure/revert scenarios.
- Proper validation of access control restrictions.
- Verification of event emissions where applicable.
- Explicit validation of state changes after each relevant function call.
- Adequate test updates whenever contract logic is modified.
- Deterministic behavior (tests should not rely on implicit execution order or shared mutable state).
- Clear and descriptive test names that reflect the intended behavior being validated.

Ensure Solidity tests cover success paths, edge cases, and revert scenarios.

# Asset files (images, fonts, etc.)
- path: "assets/**/*"
instructions: |
Review asset files for:
- Image optimization (appropriate size and format)
- Proper @2x and @3x variants for different screen densities
- SVG assets are optimized
- Font files are licensed and optimized
Review assets for optimization, proper resolution variants, and licensing.