需要审查 GitHub PR 且环境已提供 Alan…

在可使用 Alan MCP GitHub 工具（`mcp__alan__github_*`）时，按安全、正确性等维度审查 PR，并把发现以内联评论和汇总审查提交到 GitHub。

适用场景

解决思路

1. 必须使用 Alan MCP Tools：Alan MCP server 提供的 GitHub 工具已经在工具列表中，像 Read、Bash、Edit 一样作为工具调用即可，工具名前缀为 `mcp__alan__github_`。
2. 认证由 MCP server 自动处理，不需要 GitHub tokens、`gh` CLI auth、SSH keys、`.netrc` 文件、环境变量或任何凭据，零配置即可使用。
3. 禁止为获取 GitHub API 访问而执行以下操作：用 `curl` 或 `wget` 访问 api.github.com；执行 `gh` CLI 命令（`gh pr`、`gh api` 等）；用 `env | grep` 或扫描 tokens/secrets；执行 `cat ~/.netrc`、`git credential` 或 `ssh -T git@github.com`；任何查找、构造或配置 GitHub 认证的尝试；为访问 GitHub 安装 packages 或 CLIs。
4. 如果 MCP 工具调用失败，向用户报告错误；不要回退到 CLI 替代方案。
5. 开始前确认工具列表中可见 `mcp__alan__github_*` 工具；如果不可用，停止并告知用户：“The GitHub MCP tools are not available. Please check the sandbox MCP configuration.”
6. 所有 GitHub PR 工具都要求这些参数：`owner`（string，GitHub org 或用户名，例如 “supatest-ai”）、`repo`（string，仓库名，例如 “alan”）、`prNumber`（integer，PR 编号，例如 42）。示例调用：Tool: `mcp__alan__github_get_pull_request`，Parameters: `{ "owner": "supatest-ai", "repo": "alan", "prNumber": 42 }`。
7. 解析 owner/repo：如果用户只提供 PR 编号，运行 `git remote get-url origin` 获取远程 URL，再从中解析 owner 和 repo；这是 GitHub 操作中唯一应运行的 git CLI 命令，其他都使用 MCP 工具。
8. 可用的 GitHub MCP tools 包括：`mcp__alan__github_get_pull_request`（获取 PR 详情：title、state、labels、merge status）、`mcp__alan__github_get_pr_diff`（获取 PR 的 unified diff）、`mcp__alan__github_list_pr_comments`（列出 PR 所有评论）、`mcp__alan__github_list_pr_reviews`（列出 PR 所有 review）、`mcp__alan__github_list_pr_files`（列出变更文件及 additions/deletions）、`mcp__alan__github_get_issue`（获取 issue 详情）、`mcp__alan__github_get_ci_status`（获取某个 ref 的 CI check run 状态）、`mcp__alan__github_add_comment`（向 issue 或 PR 添加评论）、`mcp__alan__github_create_pr_review`（提交 review：APPROVE/REQUEST_CHANGES/COMMENT）、`mcp__alan__github_add_labels`（给 issue 或 PR 加 labels）、`mcp__alan__github_merge_pull_request`（合并 PR）、`mcp__alan__github_close_issue`（关闭 issue 或 PR）、`mcp__alan__github_request_reviewers`（请求 reviewers）。
9. 用户输入可能是：PR 编号（例如 “42” 或 “#42”）、PR URL（例如 “https://github.com/owner/repo/pull/42”）、或类似 “owner/repo#42” 的引用。
10. Workflow 第 1 步：从输入解析 owner/repo/prNumber；如果只给 PR 编号，运行 `git remote get-url origin` 解析 owner 和 repo。
11. Workflow 第 2 步：调用 `mcp__alan__github_get_pull_request`，参数 `{ owner, repo, prNumber }`，获取 title、description、state、labels、branches。
12. Workflow 第 3 步：调用 `mcp__alan__github_get_pr_diff` 获取 unified diff。
13. Workflow 第 4 步：调用 `mcp__alan__github_list_pr_files` 查看 modified/added/deleted 文件及行数统计。
14. Workflow 第 5 步：调用 `mcp__alan__github_list_pr_reviews` 查看之前的 review 状态。
15. Workflow 第 6 步：调用 `mcp__alan__github_list_pr_comments` 获取正在进行讨论的上下文。
16. Workflow 第 7 步：调用 `mcp__alan__github_get_ci_status`，传入 head branch 或 SHA；如果有 check 失败，在结果中包含 `html_url` 链接，方便用户查看完整日志（该工具不返回日志输出）。
17. Workflow 第 8 步：对于复杂变更，使用 Read 工具读取完整源文件（不只是 diff）以获取上下文。
18. Workflow 第 9 步：分析并只识别本 PR 引入的问题（不包括预先存在的问题）；对每个 finding 确定 severity、file path、start/end line、title、description，以及给 agents 的具体修复 prompt。
19. Review 维度按优先级排序：1. Security（注入、认证绕过、代码中的 secrets、输入校验）；2. Correctness（逻辑错误、null 处理、异步问题、竞态条件）；3. Performance（N+1 查询、无界操作、内存问题）；4. Error Handling（静默失败、空 catch 块、吞掉错误）；5. Maintainability（函数超过 30 行、深层嵌套、magic numbers）；6. Test Coverage（happy path 是否测试？edge cases？assertions 是否有意义？）。
20. Confidence Filter：只包含满足以下条件的 finding：能指出确切的 file + line；能描述会导致真实问题的具体场景；confidence >= 80%。跳过 linter 可捕获的问题、推测性风险、风格偏好、预先存在的问题。
21. Inline Comment Format：每个 finding 单独成为一个内联评论。每个评论的 `body` 格式为：`<!-- alan-review-comment {"id": "alan_review_{prNumber}_{sequential_4digit}", "file_path": "{path}", "start_line": {start}, "end_line": {end}, "side": "RIGHT"} -->`，然后是 `{severity_icon} **{short_title}**`，再是 `{detailed_description}`，再是 `<details><summary>Prompt for agents</summary>` 内的代码块，代码块中写明 AI agent 可执行的具体修复说明——指定确切文件、改什么、怎么改；最后加入 Alan badge begin/end：`<a href="{alan_session_url}" target="_blank"> <img src="https://app.tryalan.ai/logo.png" alt="Open in Alan" height="20"> </a>`。
22. Severity icons：🔴 = Blocking（critical bugs、security、data loss——合并前必须修复）；🟡 = Important（真实 bugs/risks——合并前应修复）；🔵 = Nit（minor quality issues——容易修就修）。
23. Summary Comment Format：review 的 `body` 参数（顶层 summary）应为：`**Alan Review** found {N} potential issues.` 表格包含 Severity 和 Count：🔴 Blocking {X}、🟡 Important {Y}、🔵 Nit {Z}；然后 `<details><summary>View all findings</summary>` 内按 severity 列出：### 🔴 Blocking、### 🟡 Important、### 🔵 Nit，每条为 `- **{title}** — \`{file_path}:{line}\` — {one_line_description}`；再包含 Alan badge；最后是 `---` 和 `*Was this helpful? React with 👍 or 👎 to provide feedback.*`。
24. Badge URL：每个 badge 都链接到当前 Alan session；用户/trigger 会提供 session URL。把每个 badge 中的 `{alan_session_url}` 替换为实际 URL；如果没有提供 session URL，回退到 `https://app.tryalan.ai`。
25. Posting the Review：调用 `mcp__alan__github_create_pr_review`，参数包括：`owner`、`repo`、`prNumber` 来自第 1 步；`body` 为上面的 summary comment；`event` 设为 `REQUEST_CHANGES`（如果有任何 🔴 blocking findings），否则设为 `COMMENT`；`comments` 是 inline comments 数组，每个包含 `path`（从 repo root 开始的相对文件路径）、`line`（finding 的结束行号）、`body`（上面格式化的 inline comment body）。
26. 发布 review 时的重要规则：始终发布 inline comments（每个 finding 一条）——不要把多个 finding 捆绑成一个大评论；始终在每个 finding 中包含 “Prompt for agents” 部分；始终在每个 comment 和 summary 中包含 “Open in Alan” badge；始终把每个 badge 中的 `{alan_session_url}` 替换为实际 session URL；如果零个 finding，发布一个带 clean summary 的 approving review。

适用边界 · 注意事项

• 当环境中没有 `mcp__alan__github_*` 工具或未配置 Alan MCP server 时，不应使用本技能。
• 当需要查看 CI 日志全文时，本工具只返回状态和 `html_url`，不返回日志输出，应通过链接查看。
• 当问题是 linter 可捕获、推测性风险、风格偏好或 PR 之前已存在时，不应作为审查发现。