opencode-pr.yml

# ---
# id: opencode/opencode-pr
# category: opencode
# type: set
# name: OpenCode AI PR Review
# description: Automated AI-powered code review for pull requests using OpenCode
# secrets:
#   - name: KIMI_API_KEY
#     description: API key for OpenCode AI service
#     required: true
# inputs: []
# triggers: [pull_request]
# variants:
#   - name: standard
#     description: Uses OpenCode GitHub Action
# ---

name: OpenCode AI PR Review

on:
  pull_request:
    types: [opened, synchronize, reopened, ready_for_review]

jobs:
  opencode:
    # Don't run on draft PRs; do run when they become ready_for_review.
    if: ${{ github.event.pull_request.draft == false }}
    runs-on: ubuntu-latest
    timeout-minutes: 10
    permissions:
      id-token: write
      contents: write
      pull-requests: write
      issues: read

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Configure git
        run: |
          git config user.name "github-actions[bot]"
          git config user.email "github-actions[bot]@users.noreply.github.com"

      - name: Run opencode
        uses: anomalyco/opencode/github@latest
        env:
          KIMI_API_KEY: ${{ secrets.KIMI_API_KEY }}
        with:
          model: kimi-for-coding/k2p5
          prompt: |
            You are reviewing a pull request. Analyze the code changes and output your review in the following STRICT STRUCTURE:

            ---

            ## 📋 Summary
            First, check if the PR description mentions any linked issues (e.g., "Closes #123", "Fixes #456", "Resolves #789"). 
            
            If linked issues are found:
            - Mention the issue number(s) explicitly
            - Verify the PR actually implements what the issue(s) requested
            - State whether the implementation fully satisfies the issue requirements
            
            Then provide 2-3 sentences summarizing the PR purpose, scope, and overall quality.

            ## 🔴 Critical Issues (Must Fix - Blocks Merge)
            Only issues that could cause crashes, security vulnerabilities, data loss, or major bugs.
            
            For each issue, use this exact format:
            ```
            **[CRITICAL]** `File:Line` - Issue Title
            **Confidence:** High|Medium|Low (how sure you are this is a real problem)
            **Description:** Clear explanation of the issue
            **Impact:** What could go wrong if merged
            **Suggested Fix:** Specific code changes needed
            ```

            ## ⚠️ High Priority Issues (Should Fix)
            Significant code quality issues, potential bugs, or architectural problems.
            
            Same format as Critical, but with **[HIGH]** prefix.

            ## 💡 Medium Priority Issues (Nice to Fix)
            Style issues, minor optimizations, or code clarity improvements.
            
            Same format, with **[MEDIUM]** prefix.

            ## ℹ️ Low Priority Suggestions (Optional)
            Minor suggestions, documentation improvements, or subjective preferences.
            
            Same format, with **[LOW]** prefix.

            ## 📊 SOLID Principles Score
            | Principle | Score | Notes |
            |-----------|-------|-------|
            | Single Responsibility | 0-10 | Brief justification |
            | Open/Closed | 0-10 | Brief justification |
            | Liskov Substitution | 0-10 | Brief justification |
            | Interface Segregation | 0-10 | Brief justification |
            | Dependency Inversion | 0-10 | Brief justification |
            | **Average** | **X.X** | |

            ## 🎯 Final Assessment

            ### Overall Confidence Score: XX%
            Rate your confidence in this PR being ready to merge (0-100%).
            **How to interpret:**
            - 0-30%: Major concerns, do not merge without significant rework
            - 31-60%: Moderate concerns, several issues need addressing
            - 61-80%: Minor concerns, mostly ready with some fixes
            - 81-100%: High confidence, ready to merge or with trivial fixes

            ### Confidence Breakdown:
            - **Code Quality:** XX% (how well-written is the code?)
            - **Completeness:** XX% (does it fulfill requirements?)
            - **Risk Level:** XX% (how risky is this change?)
            - **Test Coverage:** XX% (are changes adequately tested?)

            ### Merge Readiness:
            - [ ] All critical issues resolved
            - [ ] SOLID average score >= 6.0
            - [ ] Overall confidence >= 60%
            - [ ] No security concerns
            - [ ] Tests present and passing (if applicable)

            ### Verdict:
            **MERGE** | **MERGE WITH FIXES** | **DO NOT MERGE**
            
            One-sentence explanation of the verdict.

            ---

            **Review Guidelines:**
            1. Check the PR description for linked issues ("Fixes #123", "Closes #456", etc.) and verify the implementation
            2. Be extremely specific with file paths and line numbers
            3. Confidence scores should reflect how certain you are - use "Low" when unsure
            4. If you have nothing meaningful to add to a section, write "None identified" instead of omitting it
            5. Always provide actionable fixes, never just complaints