Back to Details

qodo-pr-resolver

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Qodo PR Resolver

Qodo PR 问题解决工具

Fetch Qodo review issues for your current branch's PR/MR, fix them interactively or in batch, and reply to each inline comment with the decision. Supports GitHub, GitLab, Bitbucket, and Azure DevOps.
获取当前分支PR/MR的Qodo审查问题，以交互式或批量方式修复，并针对每条内联评论回复处理决定。支持GitHub、GitLab、Bitbucket和Azure DevOps。

Prerequisites

前提条件

Required Tools:

必备工具：

  • Git - For branch operations
  • Git Provider CLI - One of: 
    gh
    (GitHub), 
    glab
    (GitLab), 
    bb
    (Bitbucket), or 
    az
    (Azure DevOps)
Installation and authentication details: See providers.md for provider-specific setup instructions.
  • Git - 用于分支操作
  • Git提供商CLI - 以下之一：
    gh
    （GitHub）、
    glab
    （GitLab）、
    bb
    （Bitbucket）或
    az
    （Azure DevOps）
安装与认证详情： 请参阅 providers.md 获取各提供商的具体设置说明。

Required Context:

必备上下文：

  • Must be in a git repository
  • Repository must be hosted on a supported git provider (GitHub, GitLab, Bitbucket, or Azure DevOps)
  • Current branch must have an open PR/MR
  • PR/MR must have been reviewed by Qodo (pr-agent-pro bot, qodo-merge[bot], etc.)
  • 必须处于Git仓库目录中
  • 仓库必须托管在受支持的Git提供商（GitHub、GitLab、Bitbucket或Azure DevOps）上
  • 当前分支必须有一个已打开的PR/MR
  • 该PR/MR必须已由Qodo审查（pr-agent-pro机器人、qodo-merge[bot]等）

Quick Check:

快速检查：

bash
git --version                                    # Check git installed
git remote get-url origin                        # Identify git provider
See providers.md for provider-specific verification commands.
bash
git --version                                    # 检查Git是否安装
git remote get-url origin                        # 识别Git提供商
请参阅 providers.md 获取各提供商的具体验证命令。

Understanding Qodo Reviews

理解Qodo审查

Qodo (formerly Codium AI) is an AI-powered code review tool that analyzes PRs/MRs with compliance checks, bug detection, and code quality suggestions.
Qodo（前身为Codium AI）是一款AI驱动的代码审查工具，通过合规检查、漏洞检测和代码质量建议来分析PR/MR。

Bot Identifiers

机器人标识符

Look for comments from: 
pr-agent-pro
, 
pr-agent-pro-staging
, 
qodo-merge[bot]
, 
qodo-ai[bot]
寻找来自以下账号的评论：
pr-agent-pro
、
pr-agent-pro-staging
、
qodo-merge[bot]
、
qodo-ai[bot]

Review Comment Types

审查评论类型

  1. PR Compliance Guide 🔍 - Security/ticket/custom compliance with 🟢/🟡/🔴/⚪ indicators
  2. PR Code Suggestions ✨ - Categorized improvements with importance ratings
  3. Code Review by Qodo - Structured issues with 🐞/📘/📎 sections and agent prompts (most detailed)
  1. PR合规指南 🔍 - 包含安全/工单/自定义合规检查，带有🟢/🟡/🔴/⚪标识
  2. PR代码建议 ✨ - 分类的改进建议，带有重要性评级
  3. Qodo代码审查 - 结构化问题，包含🐞/📘/📎部分和Agent提示（最详细）

Instructions

操作步骤

When the user asks for a code review, to see Qodo issues, or fix Qodo comments:
当用户请求代码审查、查看Qodo问题或修复Qodo评论时：

Step 0: Check code push status

步骤0：检查代码推送状态

Check for uncommitted changes, unpushed commits, and get the current branch.
检查是否存在未提交的更改、未推送的提交，并获取当前分支。

Scenario A: Uncommitted changes exist

场景A：存在未提交更改

  • Inform: "⚠️ You have uncommitted changes. These won't be included in the Qodo review."
  • Ask: "Would you like to commit and push them first?"
  • If yes: Wait for user action, then proceed to Step 1
  • If no: Warn "Proceeding with review of pushed code only" and continue to Step 1
  • 告知用户：“⚠️ 您有未提交的更改，这些内容不会被纳入Qodo审查范围。”
  • 询问：“是否需要先提交并推送这些更改？”
  • 如果用户选择是：等待用户操作完成，然后进入步骤1
  • 如果用户选择否：警告“将仅基于已推送的代码进行审查”，然后进入步骤1

Scenario B: Unpushed commits exist

场景B：存在未推送提交

(no uncommitted changes)
  • Inform: "⚠️ You have N unpushed commits. Qodo hasn't reviewed them yet."
  • Ask: "Would you like to push them now?"
  • If yes: Execute 
    git push
    , inform "Pushed! Qodo will review shortly. Please wait ~5 minutes then run this skill again."
  • Exit skill (don't proceed - Qodo needs time to review)
  • If no: Warn "Proceeding with existing PR review" and continue to Step 1
（无未提交更改）
  • 告知用户：“⚠️ 您有N条未推送的提交，Qodo尚未对这些内容进行审查。”
  • 询问：“是否现在推送这些提交？”
  • 如果用户选择是：执行
    git push
    ，告知用户“已推送！Qodo将很快开始审查，请等待约5分钟后再次运行本工具。”
  • 退出工具——Qodo需要时间完成审查，无需继续后续步骤
  • 如果用户选择否：警告“将基于现有PR审查内容继续操作”，然后进入步骤1

Scenario C: Everything pushed

场景C：所有代码已推送

(both uncommitted changes and unpushed commits are empty)
  • Proceed to Step 1
（无未提交更改和未推送提交）
  • 直接进入步骤1

Step 1: Detect git provider

步骤1：检测Git提供商

Detect git provider from the remote URL (
git remote get-url origin
).
See providers.md for provider detection patterns.
通过远程仓库URL（
git remote get-url origin
）检测Git提供商。
请参阅providers.md中的提供商检测规则。

Step 2: Find the open PR/MR

步骤2：查找已打开的PR/MR

Find the open PR/MR for this branch using the provider's CLI.
See providers.md § Find Open PR/MR for provider-specific commands.
使用对应提供商的CLI查找当前分支的已打开PR/MR。
请参阅providers.md § 查找已打开的PR/MR获取各提供商的具体命令。

Step 3: Get Qodo review comments

步骤3：获取Qodo审查评论

Get the Qodo review comments using the provider's CLI.
Qodo typically posts both a summary comment (PR-level, containing all issues) and inline review comments (one per issue, attached to specific lines of code). You must fetch both.
See providers.md § Fetch Review Comments for provider-specific commands.
Look for comments where the author is "qodo-merge[bot]", "pr-agent-pro", "pr-agent-pro-staging" or similar Qodo bot name.
使用对应提供商的CLI获取Qodo审查评论。
Qodo通常会发布两种评论：摘要评论（PR级，包含所有问题）和内联审查评论（每个问题对应一条，附加到具体代码行）。您需要同时获取这两种评论。
请参阅providers.md § 获取审查评论获取各提供商的具体命令。
寻找作者为“qodo-merge[bot]”、“pr-agent-pro”、“pr-agent-pro-staging”或其他类似Qodo机器人账号的评论。

Step 3a: Check if review is still in progress

步骤3a：检查审查是否仍在进行中

  • If any comment contains "Come back again in a few minutes" or "An AI review agent is analysing this pull request", the review is still running
  • In this case, inform the user: "⏳ Qodo review is still in progress. Please wait a few minutes and try again."
  • Exit early - don't try to parse incomplete reviews
  • 如果任何评论包含“请稍后再回来查看”或“AI审查Agent正在分析此拉取请求”，说明审查仍在进行
  • 此时告知用户：“⏳ Qodo审查仍在进行中，请等待几分钟后重试。”
  • 提前退出——不要尝试解析不完整的审查内容

Step 3b: Deduplicate issues

步骤3b：去重问题

Deduplicate issues across summary and inline comments:
  • Qodo posts each issue in two places: once in the summary comment (PR-level) and once as an inline review comment (attached to the specific code line). These will share the same issue title.
  • Qodo may also post multiple summary comments (Compliance Guide, Code Suggestions, Code Review, etc.) where issues can overlap with slightly different wording.
  • Deduplicate by matching on issue title (primary key - the same title means the same issue):
    • If an issue appears in both the summary comment and as an inline comment, merge them into a single issue
    • Prefer the inline comment for file location (it has the exact line context)
    • Prefer the summary comment for severity, type, and agent prompt (it is more detailed)
    • IMPORTANT: Preserve each issue's inline review comment ID — you will need it later (Step 8) to reply directly to that comment with the decision
  • Also deduplicate across multiple summary comments by location (file path + line numbers) as a secondary key
  • If the same issue appears in multiple places, combine the agent prompts
在摘要评论和内联评论之间对问题进行去重：
  • Qodo会将每个问题发布在两个位置：一次在摘要评论（PR级）中，一次作为内联审查评论（附加到具体代码行）。这些问题会共享相同的标题。
  • Qodo还可能发布多条摘要评论（合规指南、代码建议、代码审查等），其中的问题可能会有轻微不同的表述但内容重叠。
  • 通过问题标题（主键——相同标题代表同一问题）进行去重：
    • 如果一个问题同时出现在摘要评论和内联评论中，将其合并为单个问题
    • 优先使用内联评论中的文件位置信息（包含确切的代码行上下文）
    • 优先使用摘要评论中的严重程度、类型和Agent提示（内容更详细）
    • 重要提示： 保留每个问题的内联审查评论ID——后续步骤（步骤8）中需要使用此ID直接回复对应评论
  • 同时，通过位置（文件路径+行号）作为次要键对多条摘要评论中的问题进行去重
  • 如果同一问题出现在多个位置，合并其Agent提示内容

Step 4: Parse and display the issues

步骤4：解析并展示问题

  • Extract the review body/comments from Qodo's review
  • Parse out individual issues/suggestions
  • IMPORTANT: Preserve Qodo's exact issue titles verbatim — do not rename, paraphrase, or summarize them. Use the title exactly as Qodo wrote it.
  • IMPORTANT: Preserve Qodo's original ordering — display issues in the same order Qodo listed them. Qodo already orders by severity.
  • Extract location, issue description, and suggested fix
  • Extract the agent prompt from Qodo's suggestion (the description of what needs to be fixed)
  • 从Qodo的审查内容中提取评论主体/内容
  • 解析出单个问题/建议
  • 重要提示： 严格保留Qodo的原始问题标题——不要重命名、改写或总结，完全使用Qodo的原始标题。
  • 重要提示： 严格保留Qodo的原始排序——按照Qodo列出的顺序展示问题，Qodo的排序已经是按严重程度排列。
  • 提取位置、问题描述和建议修复方案
  • 从Qodo的建议中提取Agent提示（即需要修复的内容描述）

Severity mapping

严重程度映射

Derive severity from Qodo's action level and position:
  1. Action level determines severity range:
    • "Action required" issues → Can only be 🔴 CRITICAL or 🟠 HIGH
    • "Review recommended" / "Remediation recommended" issues → Can only be 🟡 MEDIUM or ⚪ LOW
    • "Other" / "Advisory comments" issues → Always ⚪ LOW (lowest priority)
  2. Qodo's position within each action level determines the specific severity:
    • Group issues by action level ("Action required" vs "Review recommended" vs "Other")
    • Within "Action required" and "Review recommended" groups: earlier positions → higher severity, later positions → lower severity
    • Split point: roughly first half of each group gets the higher severity, second half gets the lower
    • All "Other" issues are treated as ⚪ LOW regardless of position
Example: 7 "Action required" issues would be split as:
  • Issues 1-3: 🔴 CRITICAL
  • Issues 4-7: 🟠 HIGH
  • Result: No MEDIUM or LOW issues (because there are no "Review recommended" or "Other" issues)
Example: 5 "Action required" + 3 "Review recommended" + 2 "Other" issues would be split as:
  • Issues 1-2 or 1-3: 🔴 CRITICAL (first ~half of "Action required")
  • Issues 3-5 or 4-5: 🟠 HIGH (second ~half of "Action required")
  • Issues 6-7: 🟡 MEDIUM (first ~half of "Review recommended")
  • Issue 8: ⚪ LOW (second ~half of "Review recommended")
  • Issues 9-10: ⚪ LOW (all "Other" issues)
Action guidelines:
  • 🔴 CRITICAL / 🟠 HIGH ("Action required"): Always "Fix"
  • 🟡 MEDIUM ("Review recommended"): Usually "Fix", can "Defer" if low impact
  • ⚪ LOW ("Review recommended" or "Other"): Can be "Defer" unless quick to fix; "Other" issues are lowest priority
根据Qodo的操作级别和位置推导严重程度：
  1. 操作级别决定严重程度范围：
    • **“需要操作”**的问题 → 只能是🔴 严重或🟠 高
    • “建议审查” / **“建议修复”**的问题 → 只能是🟡 中或⚪ 低
    • “其他” / **“咨询评论”**的问题 → 始终为⚪ 低（最低优先级）
  2. 同一操作级别内的位置决定具体严重程度：
    • 按操作级别（“需要操作” vs “建议审查” vs “其他”）分组问题
    • 在“需要操作”和“建议审查”组内：位置越靠前 → 严重程度越高，位置越靠后 → 严重程度越低
    • 分割点：每组的前半部分问题为较高严重程度，后半部分为较低严重程度
    • 所有“其他”问题无论位置如何均视为⚪ 低
示例： 7条“需要操作”的问题将被划分为：
  • 问题1-3：🔴 严重
  • 问题4-7：🟠 高
  • 结果：无中或低严重程度问题（因为没有“建议审查”或“其他”问题）
示例： 5条“需要操作” + 3条“建议审查” + 2条“其他”的问题将被划分为：
  • 问题1-2或1-3：🔴 严重（“需要操作”组的前约一半）
  • 问题3-5或4-5：🟠 高（“需要操作”组的后约一半）
  • 问题6-7：🟡 中（“建议审查”组的前约一半）
  • 问题8：⚪ 低（“建议审查”组的后约一半）
  • 问题9-10：⚪ 低（所有“其他”问题）
操作指南：
  • 🔴 严重 / 🟠 高（“需要操作”）：必须“修复”
  • 🟡 中（“建议审查”）：通常“修复”，如果影响较小可“推迟”
  • ⚪ 低（“建议审查”或“其他”）：除非修复很快，否则可“推迟”；“其他”问题优先级最低

Output format

输出格式

Display as a markdown table in Qodo's exact original ordering (do NOT reorder by severity - Qodo's order IS the severity ranking):
Qodo Issues for PR #123: [PR Title]

| # | Severity | Issue Title | Issue Details | Type | Action |
|---|----------|-------------|---------------|------|--------|
| 1 | 🔴 CRITICAL | Insecure authentication check | • **Location:** src/auth/service.py:42<br><br>• **Issue:** Authorization logic is inverted | 🐞 Bug ⛨ Security | Fix |
| 2 | 🔴 CRITICAL | Missing input validation | • **Location:** src/api/handlers.py:156<br><br>• **Issue:** User input not sanitized before database query | 📘 Rule violation ⛯ Reliability | Fix |
| 3 | 🟠 HIGH | Database query not awaited | • **Location:** src/db/repository.py:89<br><br>• **Issue:** Async call missing await keyword | 🐞 Bug ✓ Correctness | Fix |
按照Qodo的原始顺序（不要按严重程度重新排序——Qodo的顺序就是严重程度排序）以Markdown表格形式展示：
Qodo Issues for PR #123: [PR Title]

| # | Severity | Issue Title | Issue Details | Type | Action |
|---|----------|-------------|---------------|------|--------|
| 1 | 🔴 CRITICAL | Insecure authentication check | • **Location:** src/auth/service.py:42<br><br>• **Issue:** Authorization logic is inverted | 🐞 Bug ⛨ Security | Fix |
| 2 | 🔴 CRITICAL | Missing input validation | • **Location:** src/api/handlers.py:156<br><br>• **Issue:** User input not sanitized before database query | 📘 Rule violation ⛯ Reliability | Fix |
| 3 | 🟠 HIGH | Database query not awaited | • **Location:** src/db/repository.py:89<br><br>• **Issue:** Async call missing await keyword | 🐞 Bug ✓ Correctness | Fix |

Step 5: Ask user for fix preference

步骤5：询问用户修复偏好

After displaying the table, ask the user how they want to proceed using AskUserQuestion:
Options:
  • 🔍 "Review each issue" - Review and approve/defer each issue individually (recommended for careful review)
  • ⚡ "Auto-fix all" - Automatically apply all fixes marked as "Fix" without individual approval (faster, but less control)
  • ❌ "Cancel" - Exit without making changes
Based on the user's choice:
  • If "Review each issue": Proceed to Step 6 (manual review)
  • If "Auto-fix all": Skip to Step 7 (auto-fix mode - apply all "Fix" issues automatically using Qodo's agent prompts)
  • If "Cancel": Exit the skill
展示表格后，使用AskUserQuestion询问用户希望如何继续：
选项：
  • 🔍 “逐个审查问题”——逐个审查并批准/推迟每个问题（建议用于细致审查）
  • ⚡ “自动修复全部”——自动应用所有标记为“修复”的问题，无需逐个批准（速度更快，但可控性较低）
  • ❌ “取消”——不做任何更改直接退出
根据用户选择：
  • 如果选择“逐个审查问题”：进入步骤6（手动审查模式）
  • 如果选择“自动修复全部”：跳至步骤7（自动修复模式——使用Qodo的Agent提示自动修复所有“修复”类问题）
  • 如果选择“取消”：退出工具

Step 6: Review and fix issues (manual mode)

步骤6：审查并修复问题（手动模式）

If "Review each issue" was selected:
  • For each issue marked as "Fix" (starting with CRITICAL):
    • Read the relevant file(s) to understand the current code
    • Implement the fix by executing the Qodo agent prompt as a direct instruction. The agent prompt is the fix specification — follow it literally, do not reinterpret or improvise a different solution. Only deviate if the prompt is clearly outdated relative to the current code (e.g. references lines that no longer exist).
    • Calculate the proposed fix in memory (DO NOT use Edit or Write tool yet)
    • Present the fix and ask for approval in a SINGLE step:
      1. Show a brief header with issue title and location
      2. Show Qodo's agent prompt in full so the user can verify the fix matches it
      3. Display current code snippet
      4. Display proposed change as markdown diff
      5. Immediately use AskUserQuestion with these options:
        • ✅ "Apply fix" - Apply the proposed change
        • ⏭️ "Defer" - Skip this issue (will prompt for reason)
        • 🔧 "Modify" - User wants to adjust the fix first
    • WAIT for user's choice via AskUserQuestion
    • If "Apply fix" selected:
      • Apply change using Edit tool (or Write if creating new file)
      • Reply to the Qodo inline comment with the decision (see Step 8 for inline reply commands)
      • Git commit the fix: 
        git add <modified-files> && git commit -m "fix: <issue title>"
      • Confirm: "✅ Fix applied, commented, and committed!"
      • Mark issue as completed
    • If "Defer" selected:
      • Ask for deferral reason using AskUserQuestion
      • Reply to the Qodo inline comment with the deferral (see Step 8 for inline reply commands)
      • Record reason and move to next issue
    • If "Modify" selected:
      • Inform user they can make changes manually
      • Move to next issue
  • Continue until all "Fix" issues are addressed or the user decides to stop
如果选择了“逐个审查问题”：
  • 针对每个标记为“修复”的问题（从严重程度最高的开始）：
    • 读取相关文件以理解当前代码
    • 通过严格执行Qodo的Agent提示来实现修复。Agent提示就是修复规范——必须严格遵循，不要重新解读或自行设计解决方案。只有当提示内容明显与当前代码不符时（例如引用了已不存在的代码行），才可以偏离提示。
    • 在脑海中构思修复方案（暂不使用Edit或Write工具）
    • 在单个步骤中展示修复方案并请求批准：
      1. 展示包含问题标题和位置的简要标题
      2. 完整展示Qodo的Agent提示，以便用户验证修复方案是否匹配
      3. 展示当前代码片段
      4. 以Markdown diff格式展示建议的更改
      5. 立即使用AskUserQuestion提供以下选项：
        • ✅ “应用修复”——应用建议的更改
        • ⏭️ “推迟”——跳过此问题（将询问原因）
        • 🔧 “修改”——用户希望先调整修复方案
    • 等待用户通过AskUserQuestion做出选择
    • 如果选择“应用修复”：
      • 使用Edit工具应用更改（如果是创建新文件则使用Write工具）
      • 回复Qodo的内联评论说明处理决定（请参阅步骤8的内联回复命令）
      • Git提交修复：
        git add <modified-files> && git commit -m "fix: <issue title>"
      • 确认：“✅ 修复已应用、已回复评论并提交！”
      • 将问题标记为已完成
    • 如果选择“推迟”：
      • 使用AskUserQuestion询问推迟原因
      • 回复Qodo的内联评论说明推迟决定（请参阅步骤8的内联回复命令）
      • 记录原因并处理下一个问题
    • 如果选择“修改”：
      • 告知用户可以手动进行更改
      • 处理下一个问题
  • 继续操作，直到所有“修复”类问题都已处理或用户决定停止

Important notes

重要注意事项

Single-step approval with AskUserQuestion:
  • NO native Edit UI (no persistent permissions possible)
  • Each fix requires explicit approval via custom question
  • Clearer options, no risk of accidental auto-approval
CRITICAL: Single validation only - do NOT show the diff separately and then ask. Combine the diff display and the question into ONE message. The user should see: brief context → current code → proposed diff → AskUserQuestion, all at once.
Example: Show location, Qodo's guidance, current code, proposed diff, then AskUserQuestion with options (✅ Apply fix / ⏭️ Defer / 🔧 Modify). Wait for user choice, apply via Edit tool if approved.
使用AskUserQuestion进行单步骤批准：
  • 无原生Edit界面（无法获取持久权限）
  • 每个修复都需要通过自定义问题获得明确批准
  • 选项清晰，无意外自动批准风险
关键要求： 仅进行一次验证——不要单独展示diff然后再询问。将diff展示和问题合并为一条消息。用户应看到：简要上下文 → 当前代码 → 建议的diff → AskUserQuestion选项，所有内容一次性呈现。
示例： 展示位置、Qodo的指导内容、当前代码、建议的diff，然后使用AskUserQuestion提供选项（✅ 应用修复 / ⏭️ 推迟 / 🔧 修改）。等待用户选择，如果批准则使用Edit工具应用更改。

Step 7: Auto-fix mode

步骤7：自动修复模式

If "Auto-fix all" was selected:
  • For each issue marked as "Fix" (starting with CRITICAL):
    • Read the relevant file(s) to understand the current code
    • Implement the fix by executing the Qodo agent prompt as a direct instruction. The agent prompt is the fix specification — follow it literally, do not reinterpret or improvise a different solution. Only deviate if the prompt is clearly outdated relative to the current code (e.g. references lines that no longer exist).
    • Apply the fix using Edit tool
    • Reply to the Qodo inline comment with the decision (see Step 8 for inline reply commands)
    • Git commit the fix: 
      git add <modified-files> && git commit -m "fix: <issue title>"
    • Report each fix with the agent prompt that was followed:
      ✅ Fixed: [Issue Title] at 
      [Location]
      Agent prompt: [the Qodo agent prompt used]
    • Mark issue as completed
  • After all auto-fixes are applied, display summary:
    • List of all issues that were fixed
    • List of any issues that were skipped (with reasons)
如果选择了“自动修复全部”：
  • 针对每个标记为“修复”的问题（从严重程度最高的开始）：
    • 读取相关文件以理解当前代码
    • 通过严格执行Qodo的Agent提示来实现修复。Agent提示就是修复规范——必须严格遵循，不要重新解读或自行设计解决方案。只有当提示内容明显与当前代码不符时（例如引用了已不存在的代码行），才可以偏离提示。
    • 使用Edit工具应用修复
    • 回复Qodo的内联评论说明处理决定（请参阅步骤8的内联回复命令）
    • Git提交修复：
      git add <modified-files> && git commit -m "fix: <issue title>"
    • 报告每个修复的执行情况，包含所遵循的Agent提示：
      ✅ 已修复：[问题标题] 位于
      [位置]
      Agent提示： [所使用的Qodo Agent提示内容]
    • 将问题标记为已完成
  • 所有自动修复完成后，展示总结：
    • 列出所有已修复的问题
    • 列出所有被跳过的问题（含原因）

Step 8: Post summary to PR/MR

步骤8：向PR/MR发布总结

REQUIRED: After all issues have been reviewed (fixed or deferred), ALWAYS post a comment summarizing the actions taken, even if all issues were deferred.
See providers.md § Post Summary Comment for provider-specific commands and summary format.
After posting the summary, resolve the Qodo review comment:
Find the Qodo "Code Review by Qodo" comment and mark it as resolved or react to acknowledge it.
See providers.md § Resolve Qodo Review Comment for provider-specific commands.
If resolve fails (comment not found, API error), continue — the summary comment is the important part.
必填： 所有问题审查完成后（无论修复还是推迟），必须发布一条总结评论，说明所采取的操作，即使所有问题都被推迟也不例外。
请参阅providers.md § 发布总结评论获取各提供商的具体命令和总结格式。
发布总结后，解决Qodo的审查评论：
找到Qodo的“Qodo代码审查”评论，将其标记为已解决或添加反应表示已确认。
请参阅providers.md § 解决Qodo审查评论获取各提供商的具体命令。
如果解决操作失败（未找到评论、API错误），继续后续操作——总结评论是最重要的部分。

Step 9: Push to remote

步骤9：推送到远程仓库

If any fixes were applied (commits were created in Steps 6/7), ask the user if they want to push:
  • If yes: 
    git push
  • If no: Inform them they can push later with 
    git push
Important: If all issues were deferred, there are no commits to push — skip this step.
如果应用了任何修复（步骤6/7中创建了提交），询问用户是否要推送：
  • 如果用户选择是：执行
    git push
  • 如果用户选择否：告知用户可以稍后使用
    git push
    进行推送
重要提示： 如果所有问题都被推迟，则没有需要推送的提交——跳过此步骤。

Special cases

特殊情况

Unsupported git provider

不支持的Git提供商

If the remote URL doesn't match GitHub, GitLab, Bitbucket, or Azure DevOps, inform the user and exit.
See providers.md § Error Handling for details.
如果远程仓库URL不匹配GitHub、GitLab、Bitbucket或Azure DevOps，告知用户并退出工具。
请参阅providers.md § 错误处理获取详细说明。

No PR/MR exists

不存在PR/MR

  • Inform: "No PR/MR found for branch 
    <branch-name>
    "
  • Ask: "Would you like me to create a PR/MR?"
  • If yes: Use appropriate CLI to create PR/MR (see providers.md § Create PR/MR), then inform "PR created! Qodo will review it shortly. Run this skill again in ~5 minutes."
  • If no: Exit skill
IMPORTANT: Do NOT proceed without a PR/MR
  • 告知用户：“未找到分支
    <branch-name>
    对应的PR/MR”
  • 询问：“是否需要我创建一个PR/MR？”
  • 如果用户选择是：使用对应CLI创建PR/MR（请参阅providers.md § 创建PR/MR（特殊情况）），然后告知用户“PR已创建！Qodo将很快开始审查，请约5分钟后再次运行本工具。”
  • 如果用户选择否：退出工具
重要提示： 没有PR/MR的情况下不要继续后续操作

No Qodo review yet

尚未进行Qodo审查

  • Check if PR/MR has comments from Qodo bots (pr-agent-pro, qodo-merge[bot], etc.)
  • If no Qodo comments found: Inform "Qodo hasn't reviewed this PR/MR yet. Please wait a few minutes for Qodo to analyze it."
  • Exit skill (do NOT attempt manual review)
IMPORTANT: This skill only works with Qodo reviews, not manual reviews
  • 检查PR/MR是否有来自Qodo机器人（pr-agent-pro、qodo-merge[bot]等）的评论
  • 如果未找到Qodo评论：告知用户“Qodo尚未审查此PR/MR，请等待几分钟让Qodo完成分析。”
  • 退出工具——不要尝试进行手动审查
重要提示： 本工具仅适用于Qodo审查，不适用于手动审查

Review in progress

审查正在进行中

If "Come back again in a few minutes" message is found, inform user to wait and try again, then exit.
如果发现包含“请稍后再回来查看”的消息，告知用户等待后重试，然后退出工具。

Missing CLI tool

缺少CLI工具

If the detected provider's CLI is not installed, provide installation instructions and exit.
See providers.md § Error Handling for provider-specific installation commands.
如果检测到的提供商CLI未安装，提供安装说明并退出工具。
请参阅providers.md § 错误处理获取各提供商的具体安装命令。

Inline reply commands

内联回复命令

Used per-issue in Steps 6 and 7 to reply to Qodo's inline comments:
Use the inline comment ID preserved during deduplication (Step 3b) to reply directly to Qodo's comment.
See providers.md § Reply to Inline Comments for provider-specific commands and reply format.
Keep replies short (one line). If a reply fails, log it and continue.
步骤6和7中用于回复Qodo内联评论的命令：
使用步骤3b中保留的内联评论ID直接回复Qodo的评论。
请参阅providers.md § 回复内联评论获取各提供商的具体命令和回复格式。
回复内容要简短（一行）。如果回复失败，记录日志并继续后续操作。