diff --git a/.coderabbit.yaml b/.coderabbit.yaml
deleted file mode 100644
index 6c6f70f87eb..00000000000
--- a/.coderabbit.yaml
+++ /dev/null
@@ -1,167 +0,0 @@
-# yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json
-
-# CodeRabbit Configuration for OpenSearch SQL Project
-# This configuration uses .rules/REVIEW_GUIDELINES.md for code review standards
-
-language: "en-US"
-early_access: false
-
-reviews:
-  profile: "chill"
-  request_changes_workflow: false
-  high_level_summary: true
-  high_level_summary_in_walkthrough: true
-  poem: false  # Keep reviews professional and concise
-  review_status: true
-  collapse_walkthrough: true
-  path_filters:
-    - '**/*'
-    - '!**/test/**/gen/**'
-    - '!**/.git/**'
-    - '!**/target/**'
-  auto_review:
-    enabled: true
-    auto_incremental_review: true
-    drafts: false  # Don't review draft PRs
-    ignore_title_keywords:
-      - "WIP"
-      - "DO NOT MERGE"
-      - "DRAFT"
-  
-  # Path-specific review instructions
-  path_instructions:
-    # Grammar Files - Architectural Decision Prompts
-    - path: "**/*.g4"
-      instructions: |
-        - Check if modifying unrelated grammar files (scope creep)
-        - Verify grammar rule placement follows project patterns
-        - Question if new rule needed vs reusing existing rules
-        - Ensure changes are relevant to the PR's stated purpose
-    
-    - path: "ppl/src/main/antlr/OpenSearchPPLParser.g4"
-      instructions: |
-        - Identify code reuse opportunities with existing commands
-        - Validate command follows PPL naming and structure patterns
-        - Check if command should be alias vs separate implementation
-
-    # Java Files - Apply general guidelines from REVIEW_GUIDELINES.md
-    - path: "**/*.java"
-      instructions: |
-        Apply all Java Standards from REVIEW_GUIDELINES.md
-    
-    # Core Java - Project-Specific Patterns
-    - path: "core/src/main/java/**/*.java"
-      instructions: |
-        - New functions MUST have unit tests in the same commit
-        - Public methods MUST have JavaDoc with @param, @return, and @throws
-        - Follow existing function implementation patterns in the same package
-        - New expression functions should follow ExpressionFunction interface patterns
-        - Validate function naming follows project conventions (camelCase)
-    
-    - path: "core/src/main/java/org/opensearch/sql/expression/**/*.java"
-      instructions: |
-        - New expression implementations must follow existing patterns
-        - Type handling must be consistent with project type system
-        - Error handling must use appropriate exception types
-        - Null handling must be explicit and documented
-    
-    - path: "core/src/main/java/org/opensearch/sql/ast/**/*.java"
-      instructions: |
-        - AST nodes must be immutable where possible
-        - Follow visitor pattern for AST traversal
-        - Ensure proper toString() implementation for debugging
-    
-    # Test Files - Apply testing guidelines from REVIEW_GUIDELINES.md
-    - path: "**/test/**/*.java"
-      instructions: |
-        Apply all Testing Requirements from REVIEW_GUIDELINES.md
-    
-    # Integration Tests
-    - path: "integ-test/**/*IT.java"
-      instructions: |
-        - Integration tests MUST use valid test data from resources
-        - Verify test data files exist in integ-test/src/test/resources/
-        - Check test assertions are meaningful and specific
-        - Validate tests clean up resources after execution
-        - Ensure tests are independent and can run in any order
-        - Verify integration tests are in correct module (integ-test/)
-        - Check tests can be run with ./gradlew :integ-test:integTest
-        - Ensure proper test data setup and teardown
-        - Validate end-to-end scenario coverage
-        - Do NOT flag inline test data as problematic if it improves test clarity
-        - Do NOT suggest removing helper methods that are used multiple times in the same test class
-    
-    - path: "integ-test/src/test/resources/**/*"
-      instructions: |
-        - Verify test data is realistic and representative
-        - Check data format matches expected schema
-        - Ensure test data covers edge cases and boundary conditions
-        - Do NOT flag NDJSON format as invalid JSON
-    
-    # PPL-specific
-    - path: "**/ppl/**/*.java"
-      instructions: |
-        - For PPL parser changes, verify grammar tests with positive/negative cases
-        - Check AST generation for new syntax
-        - Ensure corresponding AST builder classes are updated
-        - Validate edge cases and boundary conditions
-    
-    # Calcite Integration
-    - path: "**/calcite/**/*.java"
-      instructions: |
-        - Follow existing Calcite integration patterns
-        - Verify RelNode visitor implementations are complete
-        - Check RexNode handling follows project conventions
-        - Validate SQL generation is correct and optimized
-        - Ensure Calcite version compatibility
-        - Follow existing patterns in CalciteRelNodeVisitor and CalciteRexNodeVisitor
-        - Document any Calcite-specific workarounds
-        - Test compatibility with Calcite version constraints
-    
-    - path: "core/src/main/java/org/opensearch/sql/calcite/CalciteRelNodeVisitor.java"
-      instructions: |
-        - Flag methods >50 lines - this file is known to be hard to read
-        - Suggest extracting complex logic into helper methods
-        - Check for code organization and logical grouping
-        - Validate all RelNode types are handled
-    
-    - path: "docs/**/*.md"
-      instructions: |
-        - Verify examples use valid test data and indices
-        - Check documentation follows existing patterns and structure
-        - Validate syntax examples are complete and correct
-        - Ensure code examples are tested and working
-        - Check for consistent formatting and style
-        - Do NOT flag missing language identifiers in code blocks as critical issues
-
-chat:
-  auto_reply: false # require explicit tagging 
-  art: false # disable ASCII / Emoji art
-
-# Knowledge base configuration
-knowledge_base:
-  # Don't opt out - use knowledge base features
-  opt_out: false
-  
-  # Code guidelines - reference our custom review guidelines
-  code_guidelines:
-    enabled: true
-    filePatterns:
-      # Reference our custom review guidelines
-      - ".rules/REVIEW_GUIDELINES.md"
-  
-  # Enable web search for additional context
-  web_search:
-    enabled: true
-  
-  # Use repository-specific learnings for this project
-  learnings:
-    scope: "local"
-  
-  # Use repository-specific issues
-  issues:
-    scope: "local"
-  
-  # Use repository-specific pull requests for context
-  pull_requests:
-    scope: "local"
diff --git a/.github/workflows/coderabbit-feedback.yml b/.github/workflows/coderabbit-feedback.yml
deleted file mode 100644
index 73de49dc423..00000000000
--- a/.github/workflows/coderabbit-feedback.yml
+++ /dev/null
@@ -1,28 +0,0 @@
-name: CodeRabbit Feedback Reminder
-on:
-  pull_request_review_comment:
-    types: [created]
-permissions:
-  pull-requests: write
-jobs:
-  add-reaction-encouragement:
-    runs-on: ubuntu-latest
-    if: github.event.comment.user.login == 'coderabbitai[bot]'
-    steps:
-      - uses: actions/github-script@v8
-        with:
-          github-token: ${{ secrets.GITHUB_TOKEN }}
-          script: |
-            const comment = context.payload.comment;
-            const originalBody = comment.body;
-            const feedbackMessage = "\n\n<sub>👋 Leave emoji reaction (👍/👎) to track effectiveness of CodeRabbit.</sub>";
-
-            // Only add the message if it's not already there
-            if (!originalBody.includes(feedbackMessage)) {
-              await github.rest.pulls.updateReviewComment({
-                owner: context.repo.owner,
-                repo: context.repo.repo,
-                comment_id: comment.id,
-                body: originalBody + feedbackMessage
-              });
-            }
diff --git a/.github/workflows/pr_review.yml b/.github/workflows/pr_review.yml
new file mode 100644
index 00000000000..4c31b10cf14
--- /dev/null
+++ b/.github/workflows/pr_review.yml
@@ -0,0 +1,30 @@
+---
+name: PR Review
+on:
+  pull_request_target:
+    types: [opened, synchronize, reopened]
+
+jobs:
+  Code-Diff-Analyzer:
+    uses: opensearch-project/opensearch-build/.github/workflows/code-diff-analyzer.yml@main
+    if: github.repository == 'opensearch-project/sql'
+    permissions:
+      id-token: write  # github oidc to assume aws roles
+      pull-requests: write  # to create or update comment (peter-evans/create-or-update-comment)
+    secrets:
+      BEDROCK_ACCESS_ROLE: ${{ secrets.BEDROCK_ACCESS_ROLE }}
+    with:
+      skip_diff_analyzer_with_label_name: 'skip-diff-analyzer'
+      update_pr_comment_with_analyzer_report: true
+
+  Code-Diff-Reviewer:
+    uses: opensearch-project/opensearch-build/.github/workflows/code-diff-reviewer.yml@main
+    needs: Code-Diff-Analyzer
+    if: github.repository == 'opensearch-project/sql'
+    permissions:
+      id-token: write  # github oidc to assume aws roles
+      pull-requests: write  # to create or update comment (peter-evans/create-or-update-comment)
+    secrets:
+      BEDROCK_ACCESS_ROLE: ${{ secrets.BEDROCK_ACCESS_ROLE }}
+    with:
+      skip_diff_reviewer_with_label_name: 'skip-diff-reviewer'
diff --git a/.rules/REVIEW_GUIDELINES.md b/.rules/REVIEW_GUIDELINES.md
deleted file mode 100644
index fb97e1b80d1..00000000000
--- a/.rules/REVIEW_GUIDELINES.md
+++ /dev/null
@@ -1,132 +0,0 @@
-# Code Review Guidelines for OpenSearch SQL
-
-This document provides general code review principles and standards for the OpenSearch SQL project. These guidelines apply across all file types and are used by CodeRabbit AI for automated code reviews.
-
-## Core Review Principles
-
-### Code Quality
-- **Simplicity First**: Prefer simpler solutions unless there's significant functional or performance degradation
-- **Self-Documenting Code**: Code should be clear through naming and structure, not comments
-- **No Redundant Comments**: Avoid comments that merely restate what the code does
-- **Concise Implementation**: Keep code, docs, and notes short and focused on essentials
-- **Code Reuse**: Identify opportunities across similar implementations
-- **Maintainability**: Assess if code is easy to understand and modify
-
-### Java Standards
-- **Naming Conventions**: 
-  - Classes: `PascalCase` (e.g., `QueryExecutor`)
-  - Methods/Variables: `camelCase` (e.g., `executeQuery`)
-  - Constants: `UPPER_SNAKE_CASE` (e.g., `MAX_RETRY_COUNT`)
-- **Method Size**: 
-  - Target: Under 20 lines with single responsibility
-  - Suggest refactoring: Methods >100 lines
-- **Class Size**: Flag classes >500 lines for organization review
-- **JavaDoc Required**: All public classes and methods must have proper JavaDoc
-  - NOT required on test methods, test helpers, override methods, or private methods
-- **Error Handling**: Use specific exception types with meaningful messages
-- **Null Safety**: Prefer `Optional<T>` for nullable returns
-- **Resource Management**: Use try-with-resources for proper cleanup
-- **Dead Code**: Check for unused imports, variables, and methods
-
-### Testing Requirements
-- **Test Coverage**: All new business logic requires unit tests in the same commit
-- **Required Test Cases**:
-  - NULL input tests for all new functions
-  - Boundary condition tests (min/max values, empty inputs)
-  - Error condition tests (invalid inputs, exceptions)
-  - Multi-document tests for per-document operations
-- **Test Naming**: Follow pattern `test<Functionality><Condition>`
-- **Test Independence**: Tests must not rely on execution order
-- **Test Data**: 
-  - Use realistic data that reflects real-world scenarios
-  - Inline test data is acceptable when it improves readability
-  - Don't require loading from files if inline is clearer
-- **Test Assertions**: Flag smoke tests without meaningful assertions only if they provide no value
-- **Resource Cleanup**: Ensure proper cleanup of test resources
-- **Integration Tests**: End-to-end scenarios need integration tests in `integ-test/` module
-- **Test Execution**: Verify changes with `./gradlew :integ-test:integTest`
-- **No Failing Tests**: All tests must pass before merge; fix or ask for guidance if blocked
-
-### Code Organization
-- **Single Responsibility**: Each class should have one clear purpose
-- **Package Structure**: Follow existing module organization (core, ppl, sql, opensearch)
-- **Separation of Concerns**: Keep parsing, execution, and storage logic separate
-- **Composition Over Inheritance**: Prefer composition for code reuse
-
-### Performance & Security
-- **Efficient Loops**: Avoid unnecessary object creation in loops
-- **String Handling**: Use `StringBuilder` for concatenation in loops
-- **Input Validation**: Validate all user inputs, especially queries
-- **Logging Safety**: Sanitize data before logging to prevent injection
-
-## Review Focus Areas
-
-### What to Check
-1. **Code Clarity**: Is the code self-explanatory?
-2. **Test Coverage**: Are there adequate tests?
-3. **Error Handling**: Are errors handled appropriately?
-4. **Documentation**: Is JavaDoc complete and accurate?
-5. **Performance**: Are there obvious performance issues?
-6. **Security**: Are inputs validated and sanitized?
-
-### What to Flag
-- Redundant or obvious comments
-- Methods longer than target size (see Java Standards)
-- Missing JavaDoc on public APIs
-- Generic exception handling
-- Unused imports or dead code
-- Hard-coded values that should be constants
-- Missing or inadequate test coverage
-
-### What to Encourage
-- Clear, descriptive naming
-- Proper use of Java idioms
-- Comprehensive test coverage
-- Meaningful error messages
-- Efficient algorithms and data structures
-- Security-conscious coding practices
-
-## Project Context
-
-### OpenSearch SQL
-- **JDK 21**: Required for development
-- **Java 11 Compatibility**: Maintain when possible for OpenSearch 2.x
-- **Module Structure**: Respect existing module boundaries (core, ppl, sql, opensearch, integ-test)
-- **Test Naming**: `*IT.java` for integration tests, `*Test.java` for unit tests
-
-### Grammar and Parser Development
-- Test new grammar rules with positive and negative cases
-- Verify AST generation for new syntax
-- Include edge cases and boundary conditions
-- Update corresponding AST builder classes
-- Check for code reuse opportunities vs creating new rules
-
-### Calcite Integration
-- Follow existing patterns in visitor implementations
-- Test SQL generation and optimization paths
-- Document Calcite-specific workarounds
-- Ensure version compatibility
-
-## Review Tone and Focus
-
-### Review Priorities
-- **Correctness** > Performance > Maintainability > Style
-- Focus on functional issues, not cosmetic ones
-- Explain WHY when suggesting improvements, not just WHAT
-- Avoid repeating the same suggestion multiple times
-
-### What NOT to Flag
-- Minor refactorings unless code is clearly problematic (>100 lines, deeply nested, etc.)
-- Missing JavaDoc on test methods, test helpers, override methods, or private methods
-- Inline test data when it improves readability
-- NDJSON format as invalid JSON
-- Missing language identifiers in markdown code blocks (unless in documentation files)
-- Hard-coded test data when it's intentionally inline for clarity
-- Helper methods in tests unless they're truly unused
-- Extracting helper methods unless the method exceeds 100 lines
-
-### Keep Reviews Concise
-- Be direct and actionable
-- Focus on significant issues that impact functionality or maintainability
-- Avoid nitpicking on style preferences
-- Prioritize issues that could cause bugs or maintenance problems