MANDATORY: Use Alan MCP Tools The Alan MCP server provides GitHub tools that are ALREADY in your tool list. They work exactly like Read, Bash, Edit — you call them as tool invocations. They are named with the prefix mcp alan github . Authentication is handled automatically by the MCP server. You do NOT need GitHub tokens, gh CLI auth, SSH keys, .netrc files, environment variables, or any credentials. The tools work immediately with zero setup. NEVER do any of the following for GitHub API access: curl or wget to api.github.com gh CLI commands (gh pr, gh api, etc.) env grep or scanning for tokens/secrets cat ~/.netrc , git credential , or ssh T git@github.com Any attempt to find, construct, or configure GitHub authentication Installing packages or CLIs for GitHub access If an MCP tool call fails, report the error to the user. Do NOT fall back to CLI alternatives. Verify tools are available Before starting, confirm you can see mcp alan github tools in your available tools. If they are NOT available, STOP and tell the user: "The GitHub MCP tools are not available. Please check the sandbox MCP configuration." Tool parameters All GitHub PR tools require these parameters: owner (string): GitHub org or username, e.g. "supatest ai" repo (string): Repository name, e.g. "alan" prNumber (integer): PR number, e.g. 42 Example tool call: Resolving owner/repo If the user only provides a PR number, run git remote get url origin to get the remote URL, then parse owner and repo from it. This is the ONLY git CLI command you should run for GitHub operations. Everything else uses MCP tools. Available GitHub MCP tools Tool name Purpose mcp alan github get pull request Get PR details (title, state, labels, merge status) mcp alan github get pr diff Get unified diff of a PR mcp alan github list pr comments List all comments on a PR mcp alan github list pr reviews List all reviews on a PR mcp alan github list pr files List changed files with additions/deletions mcp alan github get issue Get issue details mcp alan github get ci status Get CI check run status for a ref mcp alan github add comment Add a comment to an issue or PR mcp alan github create pr review Submit a review (APPROVE/REQUEST CHANGES/COMMENT) mcp alan github add labels Add labels to an issue or PR mcp alan github merge pull request Merge a PR mcp alan github close issue Close an issue or PR mcp alan github request reviewers Request reviewers on a PR Task: Review a Pull Request Input The user will provide one of: A PR number (e.g. "42" or " 42") A PR URL (e.g. "https://github.com/owner/repo/pull/42") A reference like "owner/repo 42" Workflow 1. Resolve owner/repo/prNumber from the input. If only a PR number is given, run git remote get url origin to parse owner and repo. 2. Fetch PR metadata — call mcp alan github get pull request with { owner, repo, prNumber } to get title, description, state, labels, branches. 3. Fetch the diff — call mcp alan github get pr diff to get the unified diff. 4. Fetch changed files — call mcp alan github list pr files to see files modified/added/deleted with line counts. 5. Fetch existing reviews — call mcp alan github list pr reviews to see prior review state. 6. Fetch existing comments — call mcp alan github list pr comments for ongoing discussion context. 7. Check CI status — call mcp alan github get ci status with the head branch or SHA. If a check failed, include the html url link so the user can view full logs (the tool does not return log output). 8. Read source files — for complex changes, use the Read tool to read full source files (not just the diff) for context. 9. Analyze — identify issues INTRODUCED by this PR only (not pre existing). For each finding, determine: severity, file path, start/end line, title, description, and a concrete fix prompt for agents. 10. Post review — call mcp alan github create pr review with inline comments (one per finding) plus a summary body. See formats below. Review Dimensions (priority order) 1. Security — injection, auth bypass, secrets in code, input validation 2. Correctness — logic errors, null handling, async issues, race conditions 3. Performance — N+1 queries, unbounded operations, memory issues 4. Error Handling — silent failures, empty catch blocks, swallowed errors 5. Maintainability — functions 30 lines, deep nesting, magic numbers 6. Test Coverage — happy path tested? edge cases? meaningful assertions? Confidence Filter Only include findings where: You can point to exact file + line You can describe a concrete scenario where it causes a real problem Confidence = 80% Skip: linter catchable issues, speculative risks, style preferences, pre existing problems. Inline Comment Format Each finding becomes its own inline comment on the PR. Format the body of each comment like this: Severity icons: 🔴 = Blocking (critical bugs, security, data loss — must fix before merge) 🟡 = Important (real bugs/risks — should fix before merge) 🔵 = Nit (minor quality issues — fix if easy) Summary Comment Format The body parameter of the review (top level summary) should be: "Open in Alan" Badge URL Every badge links to the current Alan session. The user/trigger will provide the session URL. Replace {alan session url} in every badge with the actual URL. If no session URL is provided, fall back to https://app.tryalan.ai . Posting the Review Call mcp alan github create pr review with: owner , repo , prNumber : from step 1 body : the summary comment above event : "REQUEST CHANGES" if any 🔴 blocking findings, otherwise "COMMENT" comments : array of inline comments, each with: path : relative file path from repo root line : the end line number of the finding body : the formatted inline comment body above IMPORTANT: Always post inline comments (one per finding) — do NOT bundle into one big comment Always include the "Prompt for agents" section in every finding Always include the "Open in Alan" badge on every comment and the summary Replace {alan session url} with the actual session URL in every badge If zero findings, post an approving review with a clean summary

alan-review-pr