Qodo PR Resolver
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.
Prerequisites
Required Tools:
- Git - For branch operations
- Git Provider CLI - One of:
gh(GitHub),glab(GitLab),bb(Bitbucket), oraz(Azure DevOps)
Installation and authentication details: See providers.md for provider-specific setup instructions.
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.)
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.
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. 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
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.
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.
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.
Step 3a: Check if review is still in progress
- 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
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
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
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 logi