|
| 1 | +github: |
| 2 | + base_url: "https://api.github.com" |
| 3 | + check_name: "Amp Code Review" |
| 4 | + development_mode: true |
| 5 | + bot_username: "amp-code-review-agent" |
| 6 | + |
| 7 | +queue: |
| 8 | + max_workers: 20 |
| 9 | + max_queue_size: 100 |
| 10 | + retry_after_seconds: 60 |
| 11 | + |
| 12 | +# Diff splitting configuration |
| 13 | +diff_splitting: |
| 14 | + max_chunk_size: 500000 # 500k characters per chunk |
| 15 | + max_concurrent: 3 |
| 16 | + |
| 17 | +server: |
| 18 | + port: "${PORT:-5053}" |
| 19 | + debug: "${DEBUG:-false}" |
| 20 | + |
| 21 | +amp: |
| 22 | + timeout: "${AMP_TIMEOUT}" |
| 23 | + command: "npx --yes @sourcegraph/amp@latest" |
| 24 | + server_url: "${AMP_SERVER_URL}" |
| 25 | + settings: |
| 26 | + amp.url: "${AMP_SERVER_URL}" |
| 27 | + amp.mcpServers: |
| 28 | + github: |
| 29 | + command: "sh" |
| 30 | + args: |
| 31 | + - "-c" |
| 32 | + - "cd ${GITHUB_APP_CWD} && pnpm run mcp" |
| 33 | + env: |
| 34 | + GITHUB_APP_CWD: "${GITHUB_APP_CWD}" |
| 35 | + GITHUB_APP_ID: "${GITHUB_APP_ID}" |
| 36 | + GITHUB_APP_PRIVATE_KEY_PATH: "${GITHUB_APP_PRIVATE_KEY_PATH}" |
| 37 | + |
| 38 | + prompt_template: | |
| 39 | + Review this code diff as a senior developer. Look for bugs, clear logic errors, and code quality problems. |
| 40 | + Flag significant security concerns (leaked credentials, SQL injection, etc.), but do not mark minor concerns as issues. |
| 41 | + Likewise, flag significant performance concerns (memory leaks, deadlocks, long-lived requests), but do not mark minor concerns as issues. Do not use the oracle to review code. |
| 42 | +
|
| 43 | + Focus on: |
| 44 | + - Logic errors |
| 45 | + - Bug-prone patterns |
| 46 | + - Code quality issues |
| 47 | + - Significant security and performance problems |
| 48 | + - Obvious typos/misspellings |
| 49 | +
|
| 50 | + Pull request details: |
| 51 | + __PR_DETAILS_CONTENT__ |
| 52 | +
|
| 53 | + Diff to review: |
| 54 | + __DIFF_CONTENT__ |
| 55 | +
|
| 56 | + When reviewing code: |
| 57 | + 1. Look at the pull request details to fetch the context before reviewing. |
| 58 | + 2. Review the diff content to identify issues. |
| 59 | + 3. Leave specific inline comments or code suggestions for each issue found. |
| 60 | + 4. Create check run status when the code review is complete. |
| 61 | +
|
| 62 | + Always leave actionable, specific comments with suggested fixes. |
| 63 | +
|
| 64 | + Suggestions are optional snippets of code that can directly replace the full line the indicated issue is on. If provided, the suggestion should be just code-- no thought process included. |
| 65 | + If there is no simple code suggestion you can provide to fix the issue succinctly, provide null as the suggestion value instead. |
| 66 | + Suggestions can only be left on "new" line_type issues, not on "old" issues. For "old" issues, the suggestion should be null. |
| 67 | +
|
| 68 | + Tools available to complete the code review process: |
| 69 | + __TOOL_CONTENT__ |
| 70 | +
|
| 71 | + After you have completed the code review process: |
| 72 | + IMPORTANT: If you find any issues, include all of them in a JSON block at the end with the following format: |
| 73 | + ```json |
| 74 | + [ |
| 75 | + { |
| 76 | + "path": "filename.ext", |
| 77 | + "line": 42, |
| 78 | + "line_type": "new"|"old", |
| 79 | + "message": "Description of the issue", |
| 80 | + "suggested_fix": "if (user == \"admin\") {"|null |
| 81 | + } |
| 82 | + ] |
| 83 | + ``` |
| 84 | +
|
| 85 | + line_type must be one of "new" or "old". This is because in a diff view, the same line number can exist on both sides: |
| 86 | + Line 15 in the source (old) |
| 87 | + Line 15 in the destination (new) |
| 88 | + |
| 89 | + A suggested_fix is an optional short snippet of code that will directly replace the single full line of code the indicated issue is on in order to fix the issue. |
| 90 | + Because the suggested_fix will only overwrite the single line of code with the issue (the issue line), the suggested_fix can be either: |
| 91 | + 1. One line of code that will replace the issue line directly to address the issue. Here's an example where we fix a typo in the method invocation: |
| 92 | + Issue line: |
| 93 | + System.out.printl(foo); |
| 94 | + |
| 95 | + suggested_fix: |
| 96 | + System.out.println(foo); |
| 97 | +
|
| 98 | + 2. Multiple lines of code where the first line is the issue line and all subsequent lines are net new lines to be inserted after the issue line. |
| 99 | + Because the first line in this multi-line suggested_fix will directly replace the existing issue line, the first line can be unchanged if the suggested_fix is a pure insertion after the issue line, |
| 100 | + or the first line can differ from the issue line if the goal is to edit the issue line AND insert net new lines directly below it. Here's a pure insertion example where we add an auth check: |
| 101 | + Issue line: |
| 102 | + def access_data(user): |
| 103 | + |
| 104 | + suggested_fix: |
| 105 | + def access_user_data(user):\n\n if not user: return\n |
| 106 | + |
| 107 | + Any other cases are too complex to provide a simple suggested_fix for, so provide null as the suggested_fix value. |
| 108 | +
|
| 109 | + tools: |
| 110 | + - name: leave_general_comment |
| 111 | + description: Leave general comments on pull requests |
| 112 | + instructions: |
| 113 | + - "Use this tool to leave general comments on the pull request" |
| 114 | + - "This will post your comment to the overall pull request discussion" |
| 115 | + - "Use for summary comments, overall feedback, or general observations" |
| 116 | + - "Required: message, owner, repo, pr_number" |
| 117 | + - "Example: 'Overall the code looks good, just a few minor suggestions'" |
| 118 | + - name: leave_inline_comment |
| 119 | + description: Leave inline comments on specific lines in pull requests |
| 120 | + instructions: |
| 121 | + - "Use this tool to leave comments on specific lines of code" |
| 122 | + - "This will post your comment directly on the line in the diff view via PR review" |
| 123 | + - "Required: message, owner, repo, pr_number, path, line" |
| 124 | + - "Optional: commit_sha (will be fetched from PR if not provided)" |
| 125 | + - "Example: Comment on line 25 of src/auth.js about missing error handling" |
| 126 | + - name: create_check_run |
| 127 | + description: Create or update GitHub check run status |
| 128 | + instructions: |
| 129 | + - "Use to mark review completion with check run status" |
| 130 | + - "Required: owner, repo, commit_sha, status ('queued', 'in_progress', 'completed')" |
| 131 | + - "Optional: conclusion ('success', 'failure', 'neutral'), title, summary, details_url" |
| 132 | + - "Use 'completed' status with 'success' conclusion when review is done" |
| 133 | + - "Use 'completed' status with 'failure' conclusion for critical issues" |
| 134 | + - name: get_pr_info |
| 135 | + description: Get pull request details |
| 136 | + instructions: |
| 137 | + - "Use to understand context about the pull request before reviewing the diff" |
| 138 | + - "Required: owner, repo, pr_number" |
| 139 | + - "Optional: include_diff (boolean) to also fetch the diff content" |
| 140 | + - "Returns PR info, repository info, and optionally diff content" |
| 141 | + - name: trigger_review |
| 142 | + description: Start code review process |
| 143 | + instructions: |
| 144 | + - "Usually called automatically, but available if needed to retrigger code review" |
| 145 | + - "Required: owner, repo, pr_number" |
| 146 | + - "Optional: commit_sha, force (boolean)" |
| 147 | + - "Creates check run and initiates review process" |
| 148 | + - name: get_pr_comments |
| 149 | + description: Get all comments on a pull request |
| 150 | + instructions: |
| 151 | + - "Use to retrieve existing comments on the pull request" |
| 152 | + - "Required: owner, repo, pr_number" |
| 153 | + - "Returns array of comments and total count" |
| 154 | + - "Helpful to see what feedback has already been given before adding new comments" |
0 commit comments