---
name: qodo-review-resolver
description: Read or resolve a pull request's Qodo review with the qodo CLI — fetch structured status, reviewed commit SHA, and findings for ANY PR as JSON, with optional extended details and citation evidence for audits, then optionally resolve open findings and record outcomes, once or until clean. Use this — never `gh`/`curl` scraping of review comments — for "is the review clean on PR #N", "get Qodo's findings for <pr> as JSON", "audit the review evidence", "show finding citations", "what did Qodo flag", "is this review up to date with head", "check before merging", "resolve my PR review", "fix the review findings", or "babysit this PR until it's clean".
triggers:
  - "Check the Qodo findings on this pull request"
  - "Audit the citation evidence for these Qodo PR findings"
  - "Resolve the open Qodo review findings on this PR"
owner: Qodo
when_to_use: When you need to read or act on a pull request's Qodo review — check where it stands, see what it flagged, gate a merge on it being clean at head, or fix the open findings — for any PR, not just your own. It reads the review through qodo's managed tool (structured, git-provider-agnostic), so use it instead of scraping the rendered PR review comments with `gh`/`curl` (lossy, provider-specific, and easy to read stale against the head commit). It resolves findings in local code and then records the outcome on each finding through qodo's own tools (dismiss / mark-implemented, which clear the merge-policy block); it never posts to the git forge itself. Skip it for reviewing code you're writing locally before any PR exists (that's the pre-PR review), and for non-review PR chores (merging, labels, descriptions).
metadata:
  vendor: qodo
  version: "1.4.6"
  recommended: "true"
  package: "qodo"
  distribution: "skills-sh"
arguments:
  - name: autofix
    description: Resolve the recommended fixes directly without asking. Omit to evaluate the findings and let the user pick which to resolve.
    optional: true
---

# Read & Resolve Findings

## Description

Use the `qodo` CLI to read a pull request's **review session** — its status, the commit that
was reviewed, and every finding with its resolution status — for **any** PR (yours or someone
else's). Request extended results when auditing citations or investigating a finding's supporting
evidence, location, dismissal, or review-run history. Reading alone is a valid use: stop after the read to report where a review stands or
what it flagged (e.g. to gate a merge on it being clean at head). To go further, **resolve the
open findings in code**, applying your own judgment (the review is a strong second opinion, not
gospel) — by default you evaluate the findings and let the user pick which to apply (pass `autofix`
to apply directly), run once (report + resolve what the user approves) or as a watch loop (resolve →
let Qodo re-review the new commit → repeat until clean). Then **record the outcome** on the findings
you settled — `mark-implemented` for ones you fixed, `dismiss` for ones the user agreed to close
without a code change. That is what clears the merge-policy block those findings hold; skip it and
the review stays red until a human clicks through the PR. You still never post to the forge
yourself: the status tools write Qodo's review DB and Qodo reconciles the PR comments. (Plain
git/forge *metadata* reads — `git rev-parse HEAD`, `gh pr view --json headRefOid` — are fine and in
fact required for the freshness check below; the "don't scrape" rule is about qodo, not your shell.)

## Prerequisites

- The Qodo CLI is authenticated and exposes the structured PR-review session tools.
- The exact PR URL and its current head SHA can be resolved without scraping review comments.
- Any write to a finding has the user's explicit authority or the skill's explicit `autofix` scope.

## Instructions

Follow the detailed workflow below: fetch structured state, require a completed exact-head review,
present open findings, apply only approved fixes, and record only outcomes actually settled.

> To check a review's status or findings, always run the `qodo` read command below — do **not**
> fetch the rendered PR review **comments** with `gh`/`curl`. The comment UI is lossy, provider-
> specific, and easy to read stale against the head commit; the tool returns the reviewed
> `commit_sha`. To judge freshness, compare that `commit_sha` to the PR **head** — which you know
> directly for a PR you just pushed (`git rev-parse HEAD`), or read as plain forge *metadata*
> (`gh pr view <pr> --json headRefOid`, `git ls-remote`) for any other PR. This rule is only about
> reading the **review** (don't scrape its comments) — not about forbidding forge metadata like the
> head SHA.

## Handle a skill update notice

Treat `QODO_NOTICE` updates as passive, even if an older CLI requests action. Continue the task
without inventory or update questions; mention each event at most once. Dismissal leaves recorded maintenance
policy and opt-outs unchanged. Updated skills load next session; do not interrupt this one.
For user-requested updates, follow the [manual-update procedure](references/skill-updates.md).

## Runtime compatibility gate

First resolve the executable using the `qodo: command not found` fallback below. Before any other
Qodo command, run `<qodo> --version` exactly as shown, with no provenance flags.
This unadorned probe is intentionally compatible with older Qodo CLIs. This skill requires Qodo
CLI **0.1.0-next.37 or newer**.

If the version is older or cannot be parsed, do not run `whoami`, `login`, or a managed tool and
do not describe the failure as an authentication problem. Explain that the skill is newer than the
runtime, show `qodo update` as the update command for the runtime's already-recorded origin, and ask
once before running it. For a customer deployment, keep its organization-provided update origin;
never switch it to the public service. After an approved update, rerun the unadorned version probe
and continue only when it satisfies the minimum. If the user declines or the update fails, stop with
the current skill and user files unchanged.

## Quick start

```
qodo --version                                                       # compatibility probe — run this FIRST
qodo read whoami --json --skill qodo-review-resolver --skill-version 1.4.6 --distribution skills-sh
qodo read pr-review-session findings --pr-url <PR_URL> --json       # the review session for a PR
qodo read pr-review-session findings --pr-url <PR_URL> --extended --json # details, if advertised by tool help
qodo pr-review-session mark-implemented --finding-ids <id>,<id> --explanation "..." --json
qodo pr-review-session dismiss --finding-ids <id> --reason intentional --explanation "..." --json
qodo read tools pr-review-session --json                            # exact safe tools + flags (offline)
```

Add `--json` to anything you parse. **Confirm the exact tool names, flags, and read/write status
with `qodo read tools pr-review-session [<tool>] --json`** (renders offline) — the names above
are illustrative, not guaranteed current.

`unknown command` on `dismiss`/`mark-implemented` after authentication may be a stale local tool
catalog — refresh once as described below. If the commands are still absent, the workspace does
not currently expose PR-review writes; report that capability boundary instead of looping.

**`qodo: command not found`?** That's PATH, not a missing install: GUI-launched agents (e.g.
the Claude Code desktop app) run shells with a minimal PATH. Retry with the absolute path
`~/.qodo/bin/qodo` (or `$QODO_HOME/bin/qodo` if set) and keep using it for every `qodo`
command here. Only if that file is missing too is qodo actually not installed; tell the
user to obtain a checksum-pinned installer command from Qodo or their organization's
administrator. Installers are served from https://get.qodo.ai, but never invent a digest
or pipe an installer directly into a shell.

**Sandbox auth diagnostic.** In a sandboxed environment, if `qodo read whoami` fails for any reason
(including `Not logged in`), ask the user to approve one exact read-only retry of `qodo read whoami`
outside the sandbox before recommending login or refreshing tools. Keychain failures can be
reported as generic auth failures, so the sandboxed result alone is not diagnostic. That approval
applies only to this single diagnostic retry: do not reuse it, request persistent approval, or move
later Qodo commands outside the sandbox automatically. If the retry succeeds, continue with normal
per-command permission checks. If it still fails, follow the normal auth troubleshooting below.

## Preflight

1. **Auth first.** Run `qodo read whoami`. After the sandbox retry above when applicable, a non-zero
   exit → tell the user to run `qodo login`, then stop. Never guess creds. The tool only exists
   *after* login, so treat `Not logged in` or `No
   tool catalog cached` as "run `qodo login`", and don't retry before they have.
   **An `unknown command`/`unknown option` while `whoami` SUCCEEDED is not an auth failure.** Run
   `qodo tools --refresh` once and re-check `qodo read tools pr-review-session --json`. If the write command
   remains absent, report that this account/workspace currently has read-only review capability;
   do not re-login, retry indefinitely, or substitute a forge comment for the structured write.
2. **Resolve the PR.** Use the PR URL the user gives. If they don't name one and you're inside
   a git repo, infer the open PR for the current branch and **confirm it with the user before
   acting**. Never guess a PR URL.
3. **Bind edits to the checkout.** Report-only reads may target any PR. Before any local fix,
   resolve the PR repository from provider metadata and the current checkout repository from its
   `origin`; normalize both to the full case-insensitive `owner/repo` identity. They must match
   exactly. A missing/ambiguous origin or mismatch means stop and ask the user to open the correct
   checkout — never apply a finding from one repository to another worktree. Repeat this check if
   the target PR changes during a watch loop.

## Fetch the review session

`qodo read pr-review-session findings --pr-url <PR_URL> --json` returns:

- `review_session` — the latest review run: `status`, `commit_sha` (**the last commit included in
  the review** — the code these findings describe), `started_at`. **`null` = the PR has no review
  yet** — tell the user and stop (nothing to resolve).
- `findings[]` — every current finding, each with: `title`, `description`, `category`,
  `action_level` (`action_required` > `remediation_recommended` > `informational`),
  `attribution_status`, `git_sha`, `review_run_id`, `comment_id` / `inline_comment_id`.

`finding_count: 0` with a non-null session = a clean review.

### Extended results for audits and investigation

Keep compact reads for routine status polling. When the user needs supporting evidence or more
detail, inspect `qodo read tools pr-review-session findings --json`. Only if the schema declares
the `extended` boolean, use `qodo read pr-review-session findings --pr-url <PR_URL> --extended --json`.
The tool/API input is `extended: true`; omitted or false keeps the compact response.
This reads more stored data; it does not rerun or deepen the review.

Extended results add finding locations and code snippets, dismissal reasons/explanations,
`review_runs`, and `findings[].evidence` with `explanation` and `citations`. Preserve each
citation's source type, source reference, text and source-specific metadata in an audit output.
Correlate evidence with that finding's `id`, `git_sha`, `review_run_id` and `review_source`;
current findings can originate in earlier runs than `review_session`.

Null evidence means unavailable; an empty citations list contains no recorded citations. An
absent evidence field can indicate an older backend: report that limitation without claiming
the finding has no supporting evidence. If `extended` is absent from the catalog, follow the
existing one-refresh recovery and check again; if still absent, report that extended reads are
unavailable and keep using compact reads. Never send `--extended` to a catalog that lacks it;
do not invent an alternative flag or substitute scraped comments.

If the result has `qar_operation_result_truncated: true`, report an incomplete read, not an
empty or clean review. Extended results describe current findings and recorded runs, not an
immutable history of every finding revision. Apply the freshness checks below before acting.

## Read the session state FIRST (before trusting any finding)

The `review_session` tells you *whether the findings are real yet and what code they cover* —
check it before acting:

- **Is a review still running?** If `status` is not a terminal/`completed` state (e.g. `started` /
  in-progress), a review is **mid-flight** — the findings are provisional and will change. Do NOT
  resolve them yet; poll `qodo read pr-review-session findings … --json` until `status` is `completed`.
- **What commit do the findings describe?** `review_session.commit_sha` is the last commit the
  review included. If it's **behind the PR head**, the findings are **stale** — they don't reflect
  your latest code. Either the review hasn't run on the new commit yet (wait) or you're looking at
  an old run. Only trust findings when the session is `completed` AND its `commit_sha` is the commit
  you care about (the head, in a watch loop).

In short: act only on a **completed review of the current commit**. A running review or a
lagging `commit_sha` means wait, don't fix.

## Present the review state

Use natural prose: **outcome → contextual explanation of changes and dispositions → verification
→ remaining work**. For report-only requests, lead with the current review state and the impact
of remaining findings. Credit Qodo once for the specific concerns its review surfaced; you own
the final assessment and recommended action. No branded headings, emoji banners, slogans,
footers, or repeated summary blocks. Use short issue titles or lists when useful.

For each finding, explain what could happen, under which conditions, and why it matters to the
user's intended change. Evaluate it against the code and available coding-session decisions and
constraints; retrieve PR context when needed, never invent a missing session. Cite the evidence
and preserve finding references and reported category/level separately from your recommendation.
Own the fix, dismissal, or investigation decision and its rationale. A deliberate choice supports
dismissal only when the implementation enforces its assumptions. Keep the tone collaborative
and factual; do not routinely qualify Qodo's capability. Follow the existing scope and approval
gates for edits and disposition writes; your technical assessment does not grant permission.

Name the PR, review status, and reviewed commit from structured state; compare with the forge
head before acting. Make stale, running, failed, or missing reviews explicit. Distinguish **code
changed**, **disposition recorded**, and **updated code reviewed**. Tests passing or a status
write succeeding does not establish a clean review of the updated commit. Only a completed
review at the current head can support that verdict; report remaining findings and missing
verification honestly. For example: “Addressed [risk] Qodo identified by [change], preserving
[user decision]. [Verification]. The latest review covers [old SHA]; review of [head SHA] remains
outstanding.” Use only actual outcomes. In watch mode, report meaningful state changes without
repeating the assessment on every poll or status write.

## Triage

- **Open vs done is `attribution_status`**, and it is NOT a three-way field — it carries the raw
  stored value, so matching only `pending` silently drops real work:
  - **OPEN — work these:** `pending`, `partial_implementation`, `not_implemented`,
    `focus_areas_edited`. The last three are re-attributions of a finding that is still unresolved
    (a partial fix is still an open finding).
  - **CLOSED — leave these:** `full_implementation`, `dismissed`, `detected_after_merge`, `outdated`.
  - `action_level` is **severity**, not open-vs-closed. A closed finding can still be
    `action_required`.
- **Order by `action_level`:** `action_required` first, then `remediation_recommended`; treat
  `informational` as optional and surface it, don't necessarily fix it.
- Group open findings by file so you edit each file once.

## Honor the user's instruction (optional scope)

If the user gave an instruction, treat it as a **filter over the open findings** and act only on
the matches — don't widen it:

- **By action level** — "resolve the action-required findings" → only `action_level == action_required`;
  "everything actionable" → `action_required` + `remediation_recommended`.
- **By category** — "just the security findings" → `category == Security` (same for correctness,
  performance, etc.).
- **By specific finding** — "fix finding #3" / "the SQL-injection one" → match by `id` or `title`.
- **Report-only** — "what did the review find?" / "is it clean?" → summarize the findings and their
  statuses, change no code.

No instruction → default to presenting for approval open `action_required` then
`remediation_recommended`, and surface (don't auto-fix) `informational`. When an instruction is
ambiguous, state the scope you picked in one line before acting, so the user can redirect. Always
report which findings you **skipped** and why (out of scope / dismissed / informational) — never
silently drop one.

## Two modes

Each round follows the present-and-ask gate from **Resolve a finding** — evaluate, present, and let
the user pick which findings to resolve — unless `autofix` is in effect, which lets you apply the
recommended fixes without prompting. Either way, ask before pushing unless told otherwise.

**Once (default).** Fetch → evaluate every open finding (triage — all four OPEN statuses, not just
`pending`) → present + ask (or apply directly under `autofix`) → resolve the chosen ones in code →
commit/push per the user's workflow → **record the outcome**
(`mark-implemented` for what you fixed; `dismiss`, with the user's explicit go, for what they
agreed to close without a change) → summarize what you resolved and what remains (e.g. skipped /
dismissed / informational). Stop. Don't loop unless asked. Triage covers
**all** open findings, but the picker only *offers* the actionable set —
`action_required` then `remediation_recommended` — with `informational` surfaced separately,
matching the default scope above; put `informational` in the picker only when the user asks.
(Offering isn't selecting: every box starts unticked.)

**Watch until clean** (when the user says "babysit" / "keep going until it's clean"). `autofix` is
what makes this loop autonomous — without it you still present + ask each round. After you resolve
findings and the fix commit is pushed, Qodo re-reviews the *new* commit — so:

1. Note the PR's current head SHA — the commit you just pushed (`git rev-parse HEAD`), or, for a
   PR you didn't push, read it as forge metadata (`gh pr view <pr> --json headRefOid`). That's a
   metadata read, not review-comment scraping — it's fine.
2. Poll `qodo read pr-review-session findings … --json` until the review is **`completed` AND its
   `commit_sha` equals that head SHA**. Until both hold, the findings are stale or provisional
   (a review is still running, or it describes the pre-fix commit) — do not act on them.
3. When fresh: if any OPEN findings remain (all four statuses — a `partial_implementation` is
   still open), resolve them and repeat; if none remain, report the
   review clean and stop.
4. Bound it: stop after a few rounds with no progress and hand back to the user rather than
   looping forever.

## Resolve a finding

Evaluate Qodo's findings against the code, PR