qodo-pr-resolver

$27

Quick Check:

git --version                                    # Check git installed

git remote get-url origin                        # Identify git provider

See providers.md for provider-specific verification commands.

Understanding Qodo Reviews

Qodo (formerly Codium AI) is an AI-powered code review tool that analyzes PRs/MRs with compliance checks, bug detection, and code quality suggestions.

Bot Identifiers

Look for comments from: **pr-agent-pro, pr-agent-pro-staging, qodo-merge[bot], qodo-ai[bot]**

Review Comment Types

• PR Compliance Guide 🔍 - Security/ticket/custom compliance with 🟢/🟡/🔴/⚪ indicators

• PR Code Suggestions ✨ - Categorized improvements with importance ratings

• Code Review by Qodo - Structured issues with 🐞/📘/📎 sections and agent prompts (most detailed)

Instructions

When the user asks for a code review, to see Qodo issues, or fix Qodo comments:

Step 0: Check code push status

Check for uncommitted changes, unpushed commits, and get the current branch.

Note: Only consider tracked files when checking for uncommitted changes. Untracked files (scripts, local configs, etc.) that are not part of the repository should be ignored. Use git diff --name-only and git diff --cached --name-only rather than git status --porcelain which includes untracked files.

#### Scenario A: Uncommitted changes exist

• 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

#### Scenario B: Unpushed commits exist

(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." Record internally JUST_PUSHED = true. Continue to Step 1 (the Wait for Qodo review flow in Step 3a will handle the waiting).

• If no: Warn "Proceeding with existing PR review" and continue to Step 1

#### Scenario C: Everything pushed

(both uncommitted changes and unpushed commits are empty)

• Proceed to Step 1

Step 1: Detect git provider

Detect git provider from the remote URL (git remote get-url origin).

See providers.md for provider detection patterns. For Gerrit, also check for .gitreview file, port 29418 in remote URL, or googlesource.com — see gerrit.md.

Step 2: Find the open 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. For Gerrit, look up the change using the Change-Id from the HEAD commit message — see gerrit.md § Find Open Change.

Step 3: Get Qodo review comments

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.

Gerrit note: Qodo posts as tagged human comments via /comments with tag: "autogenerated:qodo". Also check change messages (/messages) for the summary comment. Filter by tag field or bot username. See gerrit.md § Fetch Review Comments.

#### Step 3a: Check if review is ready / Wait for Qodo review

Check if the Qodo review is complete:

• 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

• If no Qodo bot comments are found at all, the review hasn't started yet

If the review is not ready (in progress, not started, or we just pushed/created a PR):

• Ask using AskUserQuestion: "⏳ Qodo review is not ready yet. Would you like to wait for it to complete?"

• Options: "Wait for review" (Recommended) / "Exit and come back later"

• If "Exit and come back later": Inform "Run this skill again in a few minutes once Qodo has reviewed the PR." Exit skill.

• If "Wait for review":

• Inform: "Monitoring for Qodo review completion (checking every 30 seconds)..."

• Use the Monitor tool to poll for review completion:

• description: "Waiting for Qodo review on PR #"

• timeout_ms: 600000 (10 minutes)

• persistent: false

• command: A polling script that runs in a while true; do ... sleep 30; done loop. The script should use the same provider-specific comment-fetch commands from Step 3 (Fetch Review Comments) to check for Qodo bot comments. If Qodo comments are found AND they do not contain "Come back again in a few minutes" or "An AI review agent is analysing this pull request", output REVIEW_COMPLETE and exit. Use || true on API calls for transient failure resilience.

• When the Monitor emits REVIEW_COMPLETE: Inform "Qodo review is ready!" and return to Step 3 to fetch and parse the review comments normally.

• If the Monitor times out (10 minutes): Inform "Qodo review hasn't appeared yet. You can run this skill again later." Exit skill.

If the review is ready (Qodo comments found, no "in progress" markers): Proceed directly to Step 3b.

#### Step 3b: Deduplicate issues

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

Gerrit deduplication: Qodo inline comments contain an Agent Prompt section (rendered as plain text — Gerrit doesn't support expandable blocks) with detailed fix instructions. When deduplicating, preserve the Agent Prompt from each unique finding.

Step 4: Parse and display the issues

• 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)

#### Severity mapping

Derive severity from Qodo's action level and position:

-

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)

-

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

#### Output format

IMPORTANT: Use actual Unicode emoji characters (e.g. 🔴, 🟠, 📘, ⛨, ⚙), NOT GitHub-style shortcodes (:red_circle:, :books:, :shield:). Shortcodes do not render in terminal environments.

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 |

Step 5: Ask user for fix preference

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

Step 6: Review and fix issues (manual mode)

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:

• Show a brief header with issue title and location

• Show Qodo's agent prompt in full so the user can verify the fix matches it

• Display current code snippet

• Display proposed change as markdown diff

• 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)

• GitHub / GitLab / Bitbucket / Azure DevOps: Git commit the fix: git add <modified-files> &#x26;&#x26; git commit -m "fix: <issue title>"

• Gerrit: Do NOT commit yet — stage the change (git add <modified-files>) but wait until all fixes are applied, then amend into a single commit (see Gerrit note below)

• Confirm: "✅ Fix applied!"

• Mark issue as completed

• If "Defer" selected:

• Ask for deferral reason using AskUserQuestion

• 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

• After all fixes are applied, reply to all Qodo inline comments in one batch (see Step 8)

Gerrit commit strategy: In Gerrit, each commit becomes a separate change. To keep all fixes as a single new patchset on the existing change:

• Apply all fixes (Edit tool) and stage them (git add)

• After ALL fixes are done, amend the original commit: git commit --amend --no-edit

• Push once in Step 9

Do NOT create individual commits per fix for Gerrit.

#### 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.

Step 7: Auto-fix mode

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

• GitHub / GitLab / Bitbucket / Azure DevOps: Git commit the fix: git add <modified-files> &#x26;&#x26; git commit -m "fix: <issue title>"

• Gerrit: Stage only (git add <modified-files>) — do NOT commit yet

• 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

• Gerrit: After ALL fixes are applied, amend into one commit: git commit --amend --no-edit

• Reply to all Qodo inline comments in one batch (see Step 8)

• After all auto-fixes are applied, display summary:

• List of all issues that were fixed

• List of any issues that were skipped (with reasons)

Step 8: Post summary and reply to comments

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.

Gerrit: Batch the summary comment AND all inline replies into a single API call. This is more efficient and avoids multiple email notifications. Use the unified review endpoint with both message (summary) and comments (inline replies) — see gerrit.md § Post Summary Comment.

Important resolution rules for inline replies:

• Fixed issues: set "unresolved": false (resolves the thread)

• Deferred issues: set "unresolved": false (resolves the thread — the next Qodo review will re-evaluate)

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.

Step 9: Push to remote

If any fixes were applied (commits were created in Steps 6/7), ask the user if they want to push:

• If yes: git push (for Gerrit: git push origin HEAD:refs/for/<target-branch> — this creates a new patchset on the existing change, matched by the Change-Id in the commit message. See gerrit.md § Push Changes)

• 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.

Step 9b: Handle draft PR status

**Only run this step if DRAFT_PR_CREATED = true** (a draft PR was created earlier in this session). Skip entirely if the PR already existed or was created as a regular PR.

• Ask using AskUserQuestion: "We opened this PR as a draft. Would you like to mark it as ready for review, or keep it as a draft?"

• Options: "Mark as ready for review" / "Keep as draft"

• If "Mark as ready for review": Use provider CLI to mark PR as ready (see providers.md § Mark PR Ready for Review). Inform: "PR marked as ready for review!"

• If "Keep as draft": Inform: "PR will remain as a draft. You can mark it ready later."

Step 10: Show PR URL

After completing all steps, always echo the PR/MR URL to the user so they can easily navigate to it. Use the PR URL detected in Step 2.

Example output: 🔗 PR: https://github.com/owner/repo/pull/123

For Gerrit: 🔗 Change: https://<gerrit-host>/c/<project>/+/<change-number>

Special cases

#### Unsupported git provider

If the remote URL doesn't match GitHub, GitLab, Bitbucket, Azure DevOps, or Gerrit, inform the user and exit.

See providers.md § Error Handling for details.

#### No PR/MR exists

• Inform: "No PR/MR found for branch <branch-name>. A PR is needed to trigger a Qodo review."

• For non-Gerrit providers, ask using AskUserQuestion: "How would you like to proceed?"

• "Open draft PR" (Recommended) — Create a draft PR since the code isn't finalized yet. Use provider CLI with draft flag (see providers.md § Create PR/MR). Record internally: DRAFT_PR_CREATED = true and save the PR number/ID. Inform "Draft PR created!" then proceed to the Wait for Qodo review flow (Step 3a).

• "Open PR" — Create a regular (non-draft) PR. Use provider CLI without draft flag (see providers.md § Create PR/MR). Set DRAFT_PR_CREATED = false. Inform "PR created!" then proceed to the Wait for Qodo review flow (Step 3a).

• "I'll open it manually" — Inform: "No problem! Open the PR yourself, then run this skill again once the PR exists and Qodo has reviewed it." Exit skill.

• For Gerrit, ask: "Would you like me to create a change?" If yes, push with git push origin HEAD:refs/for/<branch> (see gerrit.md § Create Change). Then proceed to the Wait for Qodo review flow (Step 3a). If no, exit skill.

IMPORTANT: Do NOT proceed to Step 3b without a PR/MR. This skill only works with Qodo reviews, not manual reviews.

#### No Qodo review yet / Review in progress

Handled by Step 3a — proceeds to the Wait for Qodo review flow.

#### Missing CLI tool

If the detected provider's CLI is not installed, provide installation instructions and exit.

See providers.md § Error Handling for provider-specific installation commands.

#### 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. For Gerrit, all replies go through a single unified endpoint and can be batched — see gerrit.md § Reply to Comments.

Keep replies short (one line). If a reply fails, log it and continue.