Update to Qodo

{
  "description": "Review local changes with Qodo during substantive coding milestones and before a PR or completed-work handoff. Use light background checkpoints while coding, collect and assess findings with session context, and run a final review before handing off. Also use for \"review my local diff\", \"pre-PR review\", or \"run qodo review\". Use qodo-review-resolver for findings already posted on a PR.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 343
    },
    {
      "relative_path": "references/connected-progress.md",
      "size_in_bytes": 2293
    },
    {
      "relative_path": "references/finding-results.md",
      "size_in_bytes": 3661
    },
    {
      "relative_path": "references/local-triage.md",
      "size_in_bytes": 2896
    },
    {
      "relative_path": "references/review-turn-context.md",
      "size_in_bytes": 2289
    },
    {
      "relative_path": "references/skill-updates.md",
      "size_in_bytes": 1685
    },
    {
      "relative_path": "references/windows-launcher.md",
      "size_in_bytes": 1203
    },
    {
      "relative_path": "references/windows-shells.md",
      "size_in_bytes": 917
    }
  ],
  "name": "qodo-review",
  "skill_md_contents": "---\nname: qodo-review\ndescription: Review local changes with Qodo during substantive coding milestones and before a PR or completed-work handoff. Use light background checkpoints while coding, collect and assess findings with session context, and run a final review before handing off. Also use for \"review my local diff\", \"pre-PR review\", or \"run qodo review\". Use qodo-review-resolver for findings already posted on a PR.\nowner: Qodo\nmetadata:\n  vendor: qodo\n  version: \"1.10.11\"\n  recommended: \"true\"\n  package: \"qodo\"\n  distribution: \"marketplace\"\n  instruction_mode: \"embedded\"\n---\n\n# Local Review\n\n## Description\n\nReview **local changes during coding and before handing off completed work**. `qodo review` sends your diff, new/untracked files and coding-session context to Qodo. Evaluate its structured findings and apply authorized fixes. Only the base commit must be on the remote; the command never pushes or creates a PR.\n\nUse this skill for local changes, including unpushed work on an existing PR. Use `qodo-review-resolver` to work on findings from the PR's remote review; do not duplicate that review for an unchanged pushed snapshot.\n\n## Prerequisites\n\n- An authenticated Qodo CLI is available, or a connected QAR MCP server and a tested local input collector are available; review capability is enabled.\n- The comparison base exists on the remote; local changes and context need not be pushed.\n- The coding-session context and any ticket or design references are ready to attach.\n\n## Choose when and how deeply to review\n\n| Situation | Selection |\n|---|---|\n| A coherent milestone during substantive coding | `--fast --async`: light checkpoint; continue useful coding and collect the result. |\n| Ordinary final review before opening/updating a PR or handing off completed work | Omit both depth flags: auto. Collect and assess the result before claiming review completion. |\n| User intent calls for unusually thorough scrutiny, or a known high blast radius warrants it | `--deep`, with a brief reason tied to the request or affected behavior. |\n\nAutomatic coding checkpoints always use `--fast`. A deliberate deep review can happen earlier when\none of the exceptions above applies. A request such as \"examine subtle races thoroughly\" can justify\nit without the word \"deep\"; generic \"review\" or \"double-check\" does not. Identify concrete impact,\nsuch as shared authorization, a destructive migration, or a contract used by multiple services.\nDiff size, session length, PR readiness, or a security-related filename alone do not justify deep.\n\nWith **no flag**, the CLI omits depth and the reviewer/deployment selects it. Auto can select deep;\nit is not guaranteed standard and does not impose a spending cap. There is no `--standard` flag.\n`--fast` and `--deep` are mutually exclusive; depth is selected anew for each invocation.\n\n## Checkpoints and final handoff\n\n- Review a completed, testable slice when its feedback can guide the remaining work. Do not review\n  unfinished exploration, every edit, trivial changes automatically, or simply because time passed.\n  Respect the user's review scope and budget. A pause for a question or approval is not a final handoff.\n- Keep at most one automatic checkpoint active per task. Retain its operation ID, submitted scope\n  and snapshot/context association in the task's existing state. Poll status at natural pauses while\n  doing useful work; do not launch another review to check progress or re-review unchanged inputs.\n- Collect every submitted result within its retention window. Recheck findings against current code\n  before acting: the working tree may have changed. A superseded result cannot certify newer work.\n  Use the existing CLI lifecycle; no separate sub-agent or scheduler is required.\n- Before final review, collect the outstanding checkpoint and reconcile its findings. Review the\n  full intended change with auto, or justified deep, rather than handing off on a light checkpoint.\n  Remove temporary path restrictions that would leave part of the intended change unreviewed.\n  If the same snapshot already has completed final coverage with compatible context, use that result.\n- Batch authorized fixes, verify them, then re-review changed work. Keep `--fast` for checkpoint\n  fixes; retain the requested auto or justified deep mode for final-review fixes. Let the engine\n  determine incremental eligibility; auto may route differently on each pass. Do not manually switch\n  final fixes to `--fast` or force `--deep` just to pin auto routing. If work returns to substantial\n  implementation, resume light checkpoints and establish final coverage again before handoff.\n- If another pass repeats the same concern without actionable progress, stop the automatic loop and\n  report the remaining issue and needed decision/check. Do not buy repeated passes to chase zero.\n  Pending, failed, partial or superseded review is not clean; surface remaining findings and coverage.\n\n## Prepare a PR handoff\n\nWhen preparing to open or update a PR, prefer committing the intended changes before final local review, following the user's commit policy. Git reviews that support local-to-PR handoff can continue from that verified commit.\nCommit and review later edits again to include them. Committing is optional; without a usable reviewed commit, Git review follows its normal scope.\nFor authorized notes maintenance, use `qodo-review-notes` to find the track, publish existing-HEAD PR notes before opening, refresh if HEAD changes, and bind afterward; retain local review context and verify consumption separately.\n\n## Instructions\n### Choose the execution path\n\nPrefer `qodo review` when available: it gathers and filters tracked and untracked local changes, resolves the remote base, attaches context, and manages checkpoint state. The QAR MCP\n`start-pre-pr-review` tool instead accepts a prepared `diff`, `base_sha`, repository locator, and context; it cannot read this worktree. Use that MCP tool only when a tested local collector\nhas produced the same intended scope and exclusions, reported omitted files, and verified that the base SHA is fetchable. Do not assemble an ad hoc `git diff` and call it equivalent coverage.\nIf no collector is available, report that MCP-only local review cannot safely cover this worktree; do not claim a completed review.\n\nFor a prepared MCP review, inspect the live schema. Set `review_scope.stream_id` to exactly 64 lowercase hexadecimal characters: SHA-256 of a JSON array containing the resolved real worktree root, plus the resolved working directory for path-limited reviews. Reuse it across checkpoints; a UUID is invalid.\nRetain the same `request_id` and exact arguments for an uncertain start: `request_id` is this start tool's logical-action retry key, and no separate `idempotency_key` argument is declared. Poll `get-managed-agent-operation` at its advertised interval, then fetch all `get-managed-agent-result` chunks and verify their reported digest and byte count before interpreting the artifact.\nThese are short lifecycle calls, not MCP Tasks. Check `isError` before reading a receipt. Apply the same context, depth, coverage, finding, and authority rules below. CLI version, identity, and command instructions below apply only to the CLI path.\n\nPreserve notices, attach self-contained context, show progress, use a suitable timeout,\nread the structured result, and act on findings.\n\n## Handle a skill update notice\nTreat `QODO_NOTICE` updates as passive, even if an older CLI requests action. Continue the task\nwithout inventory or update questions; mention each event at most once. Dismissal leaves recorded maintenance\npolicy and opt-outs unchanged. Updated skills load next session; do not interrupt this one.\nFor user-requested updates, follow the [manual-update procedure](references/skill-updates.md).\n\n## Execution\n\n- MCP: use live schema arguments; skip CLI shell steps.\n- CLI: use complete UTF-8 files without a BOM (`--args-file` for tools, `--context-file` for reviews); examples are POSIX.\n- Windows CLI: read [shell guidance](references/windows-shells.md) before the first call; [launcher recovery](references/windows-launcher.md) only if invocation fails. Reuse the resolved invocation.\n\n## Runtime compatibility gate\nResolve the executable using this skill's command-not-found fallback, then run `<qodo> --version`\nwith no provenance flags. This skill requires Qodo CLI **2.0.0 or newer** and a runtime with review API v2.\nIf older or unparseable, do not run `whoami`, `login`, or a review, and do not call it an auth failure.\nAutomatic updates stay within a major version; ask once before explicit 2.x installation with a\nchecksum-pinned installer supplied by Qodo or the organization. Preserve the recorded origin and\nnever invent a digest. Recheck the version after installation; otherwise stop without changing files.\n\n## Quick start\nYou just wrote the code, so you hold the one input the reviewer can't get anywhere else: **why**.\nAttach it on every run — write the session context first, then review:\nBefore each new submission, read [Session context](references/review-turn-context.md) and refresh `recent_work`.\nExamples use `notes`; check `qodo review --help`. If it advertises only `summary`, use that field\nfor the same narrative, keeping `decisions` and `recent_work` unchanged.\n\n```\nqodo --version                                  # compatibility probe — run this FIRST\nqodo read whoami --json --skill qodo-review --skill-version 1.10.11 --distribution marketplace --host codex\nreview_base=$(git merge-base HEAD origin/main) || { printf '%s\\n' 'Cannot resolve merge base for origin/main; fetch missing history or choose the correct target.' >&2; exit 1; } # use the intended target branch\nqodo review --base \"$review_base\" --context-file - <<'EOF' # branch changes, WITH context\n{ \"notes\": \"<expected behavior, constraints, supporting evidence and uncertainty>\",\n  \"decisions\": [\"<actual choice, its user/agent owner, and known rationale>\"],\n  \"recent_work\": [\"<what changed since the previous review; fixes only or added behavior>\"] }\nEOF\nqodo review --base \"$review_base\" --context-file ctx.json # context from a file\nqodo review --base \"$review_base\" --ticket <TICKET_URL> ... # ticket URL (repeatable)\nqodo review --base \"$review_base\" --json ...              # machine-readable findings\nqodo review --base \"$review_base\" src/ test/ ...          # limit to paths (git pathspecs)\ndevelop_review_base=$(git merge-base HEAD origin/develop) || { printf '%s\\n' 'Cannot resolve merge base for origin/develop; fetch missing history or choose the correct target.' >&2; exit 1; } # another target branch\nqodo review --base \"$develop_review_base\" --json --context-file ctx.json # another target branch\nqodo review --base \"$review_base\" --fast --async --json --context-file ctx.json # checkpoint\nqodo review --base \"$review_base\" --json --context-file ctx.json      # final: auto\nqodo review --base \"$review_base\" --deep --json --context-file ctx.json # justified deep review\nqodo review --base \"$review_base\" # no context only when there is truly nothing to say\nqodo review status <operation-id>            # collect an --async result (exit 2 = still running)\nqodo review --help                           # exact flags (renders offline)\n```\n\nYou can also keep `.qodo/session-context.json` (same JSON shape) updated at the repo root — it is auto-attached to every run, so even a bare `qodo review` carries your context. An explicit\n`--context-file` overrides it; the file itself is never part of the reviewed diff. Don't commit it\n(add `.qodo/` to `.gitignore` or `.git/info/exclude`).\nAdd `--json` to anything you parse. For connected execution, allow a multi-minute timeout or\nbackground the process; async submission and status collection are separate short calls.\n**Confirm the exact flags with `qodo review --help`** (offline) — the examples here are illustrative.\n\n## Choose execution for the selected review\n\nUse `--async` for coding checkpoints: submit, continue useful work, then collect with `review status`.\nFor a final review, async is also valid, but collect and assess it before the handoff. If live progress\nis useful, read [connected progress](references/connected-progress.md) and use `--json --progress`\nwith a host-native background process. Never combine `--progress` with `--async`.\nA review can take minutes; keep a connected process alive or use async so client exit cannot cancel it.\nIf async is unavailable in the installed CLI, keep the selected depth and use the connected fallback.\n\nFor connected progress, the canonical execution rules are:\n\n- Attach context through a file; stdin heredocs are unsuitable for background execution.\n- Use a unique per-run temporary directory. Separate the single result JSON on stdout from NDJSON\n  progress on stderr. Poll the growing progress file through the host's nonblocking process tools;\n  never run a foreground `tail` that blocks the agent until completion.\n- Relay short status messages, not raw JSON or model output. Translate events by `kind`:\n  `cli.status` gives a readable message; `tool.activity` gives tool name and outcome;\n  `task.delta` and unknown kinds are occasional generic heartbeats, not one message per event.\n- For `qar.client.reconnecting`, relay attempt/delay and structured close/error codes when present.\n  `qar.client.reconnected` means transport opened; `resubscribeAttempts` counts reattached live tasks.\n  `qar.client.reconnect_failed` signals exhausted retries, not the final error explanation.\n- On `task.done`, inspect `payload.status`; on failure/cancellation or `error`, stop progress relay\n  but keep waiting for process exit. Always read the result envelope, including on nonzero exit:\n  actionable messages/hints such as `closed_preview` may appear only there. Progress is not findings.\n- Capture the process exit status, reap the child and disarm its PID before parsing. On interruption,\n  terminate and reap the active child. Clean up only that run's directory on exit/failure/interruption;\n  never reuse or remove a shared `.qodo/review.*` path.\n- If background progress is unavailable, run foreground with a multi-minute timeout, preserving\n  selected depth and context. Missing progress is not a reason to fail review or downgrade depth.\n\n**`qodo: command not found`?** On POSIX retry `\"${QODO_HOME:-$HOME/.qodo}/bin/qodo\"`;\non Windows follow the linked guide. Keep the resolved invocation; report unusable launchers.\nFor missing installs, obtain Qodo's or the administrator's checksum-pinned installer; never invent a digest or pipe scripts into a shell.\n\n**Sandbox auth diagnostic.** Missing credentials can mean inaccessible keychain access. When that\nis plausible, request one exact read-only `qodo read whoami` retry through the host's approval\nflow before recommending login. Stop on denial; that approval covers no other command. Reuse a\nsuccessful check in the same executable/workspace/deployment and execution context; request each\nrequired host approval. Network, TLS, service, and explicit authorization failures retain their\nown diagnosis, not a login recommendation or an automatic sandbox bypass.\n\n## Submit and collect with `--async`\n\nCheck support with `qodo review --help`. The following example submits a coding checkpoint. For final\nreview omit `--fast`; add `--deep` only under the selection policy above. Attach the same context in\nall modes. Shell snippets illustrate the CLI protocol; use the host's own nonblocking wait mechanism.\n\n`--async` removes the connection from the critical path. It submits the review over HTTP, prints an\n**operation id**, and exits 0 immediately. The run continues server-side whether or not your process\nis alive; you collect the result later with `qodo review status <operation-id>`.\n\n```\ncommand -v jq >/dev/null 2>&1 || { printf '%s\\n' 'This async recipe requires jq; install it or use the live qodo review flow.' >&2; exit 1; }\nQODO_REVIEW_CONTEXT=\"${QODO_REVIEW_CONTEXT:-.qodo/session-context.json}\"\n[ -f \"$QODO_REVIEW_CONTEXT\" ] || { printf '%s\\n' \"Write the required review context to $QODO_REVIEW_CONTEXT (or set QODO_REVIEW_CONTEXT to its path).\" >&2; exit 1; }\nQODO_REVIEW_BASE=\"$(git merge-base HEAD origin/main)\" || { printf '%s\\n' 'Cannot resolve merge base for origin/main; fetch missing history or choose the correct target.' >&2; exit 1; } # substitute the intended target\nif ! submission=\"$(qodo review --base \"$QODO_REVIEW_BASE\" --context-file \"$QODO_REVIEW_CONTEXT\" --async --json --fast)\"; then printf '%s\\n' \"$submission\" >&2; exit 1; fi\nif ! id=\"$(printf '%s\\n' \"$submission\" | jq -er '.operation_id | select(type == \"string\" and length > 0)')\"; then printf '%s\\n' \"$submission\" >&2; exit 1; fi\nqodo review status \"$id\" --json                                # collect it\n```\n\nPoll the existing operation until it finishes; do useful work between status checks. Submission\nexit 0 means accepted, not reviewed. Collection uses these exit codes; read any returned retry delay:\n\n| Exit | Meaning | Do |\n|---|---|---|\n| `0` | Finished. Findings rendered — **identical** output to a live run (`{findings, meta}` under `--json`). | Act on the findings as usual. |\n| `2` | Still running or polling throttled. | Respect `retry_after` when present, then poll the same ID. |\n| `1` | Failed, canceled, expired, or no such operation. Read the `error` envelope. | Follow the bounded recovery below; never assume clean. |\n\n```\n# This collection attempt returns failures to the host for classification under Recover a review.\n# On nonzero exit, preserve the operation ID and emitted error; apply bounded recovery there.\nQODO_REVIEW_TMP=\"$(mktemp -d \"${TMPDIR:-/tmp}/qodo-review.XXXXXX\")\"\ncleanup_qodo_review() { [ -n \"${QODO_REVIEW_TMP:-}\" ] && [ -d \"$QODO_REVIEW_TMP\" ] && rm -r -- \"$QODO_REVIEW_TMP\"; }\ntrap cleanup_qodo_review EXIT; trap 'exit 130' INT; trap 'exit 143' TERM\nwhile :; do\n  status=0; qodo review status \"$id\" --json > \"$QODO_REVIEW_TMP/result.json\" || status=$?\n  case \"$status\" in\n    0) cat \"$QODO_REVIEW_TMP/result.json\" || exit 1; break ;;\n    2) delay=$(jq -r 'if (.retry_after | type) == \"number\" and .retry_after > 0 then .retry_after else 15 end' \"$QODO_REVIEW_TMP/result.json\") || exit 1\n       sleep \"$delay\" ;;\n    *) cat \"$QODO_REVIEW_TMP/result.json\" >&2; exit \"$status\" ;;\n  esac\ndone\n```\n\n**What it costs — know these before you choose it:**\n\n- **No streaming progress.** There are no progress events on this path — the run isn't attached to\n  your process — so `--async` and `--progress` are rejected together rather than emitting a stream\n  that never arrives. There is no intermediate status beyond \"still running\". If the user is\n  watching and wants to see life, use the [connected progress](references/connected-progress.md) recipe instead.\n- **No human-in-the-loop.** This surface runs deterministic agents only; a review that asks for\n  input fails instead of waiting. (`qodo review status` says so and tells you to re-run without\n  `--async`.)\n- **The result is kept for 1 hour** after the review finishes, then it is discarded. Collect it\n  inside that window. Past it, `qodo review status` cannot tell \"expired\" from \"never existed\" or\n  \"belongs to someone else\" — the runtime answers all three identically, on purpose — so it reports\n  all of them. Report the missing review evidence before deciding whether a new run is needed.\n- **Do not assume a new submission is free or deduplicated.** Use `review status` to collect an\n  accepted run. If admission is uncertain, follow the CLI's returned recovery command (on versions\n  that support it, `--async --retry-submission <id>`); never substitute a fresh `qodo review` to poll.\n  Preserve the retained request during recovery instead of gathering the changing working tree again.\n- **Retain the operation id.** It identifies the accepted run; a submission-recovery ID has a different\n  purpose. Do not throw away either handle before collecting or reconciling its outcome.\n\n**The operation id is not the `trace` id.** `qodo` prints a `trace <id>` line on failures — that's\nan OpenTelemetry id for support to diagnose a run with, and it cannot fetch anything. The\n`operation_id` from `--async` is the resumable handle. Don't pass one where the other is wanted.\n\n## Preflight\n\n1. **Auth and catalog.** Run `qodo read whoami` unless a successful check still covers this\n   execution context. After the sandbox diagnostic when applicable, only explicit missing credentials\n   call for login: preserve the organization's exact login command/endpoint, never guess or switch\n   a customer deployment to Cloud. `No tool catalog cached` is not proof of missing credentials;\n   refresh once with `qodo tools --refresh` and retry the check. Other failures retain their error\n   and stop this workflow. After identity succeeds, an unknown managed command permits one catalog\n   refresh and schema recheck. If still absent or `tool_unavailable`, report the missing capability;\n   do not repeat login or refresh.\n   An unknown built-in `qodo review` needs runtime recovery, not login or catalog refresh.\n2. **Resolve the base.** Select the intended target (`origin/main` unless the change targets another\n   branch). Fetch that target before reviewing current remote history; if unavailable or deliberately\n   offline/pinned, disclose that the review uses locally fetched history rather than claim it is current.\n   Compute `git merge-base HEAD <target-ref>` and pass that SHA as `--base` on every\n   submission, including checkpoints and connected runs. This also protects older CLIs whose\n   default compares the target tip. An explicit `--base` is exact; passing the target branch itself\n   can misattribute newer target-only changes. Honor a user-requested exact comparison.\n   If no common ancestor is available, fetch missing history or report the blocker; never fall\n   back silently to the target tip. The base must be pushed; review authority does not allow a push.\n   Local edits and untracked files are included without committing or pushing them.\n3. **Write your context.** Capture actual choices and natural-language ownership in `decisions`,\n   review context/evidence in `notes`, and this round's work in `recent_work`. Refresh facts and\n   verification results before review. Follow the SessionContext guidance below; leave unknown\n   ownership or rationale explicit.\n\n## What gets reviewed\n\n`qodo review` gathers, all client-side:\n\n- The **tracked diff** vs the base, plus **new/untracked files** (secrets, binaries, oversized,\n  and gitignored files are filtered out and reported — never silently dropped).\n- The **branch name**, **HEAD commit**, and a **description** synthesized from your commit messages.\n- Any **ticket refs** and **session context** you attach (below).\n\n`--json` returns each finding once in `findings`; `finding_state` buckets reference IDs. Assess `.introduced`\n**and** `.still_open`; report detected fixes in `.resolved` and stored dismissals in `.dismissed`. Older buckets contain full objects.\nDefault fields: `id`, `title`, `description`, `category`, `action_level`, `attribution_status`, `git_sha`,\n`location`, `evidence.citations`. Inspect the code location and evidence; preserve the original finding ID.\n`--extended` adds stored supporting detail; it changes neither review depth nor execution.\nLocal `review_agent_comment` is stored reviewer feedback in both views; reuse carries it forward without new execution. Read it alongside findings and coverage.\nFor authorized status writes, group IDs by `meta.local_review_ids[id]`; report unavailable references.\nFix instructions and reviewer internals are excluded. See the [field guide](references/finding-results.md) for field details.\nIf `finding_state.complete` or `meta.coverage.complete` is false, report the incomplete coverage.\n`meta.analysis.mode` is `full`, `incremental`, or `reused`. Reused means the same reviewed snapshot\nand compatible context; earlier open findings remain open. The CLI privately saves the submitted patch.\nIt advances its checkpoint after collecting an eligible result, including via `review status`; failed or older completions cannot replace a newer checkpoint.\nKeep the same base, path scope, requested depth mode and context during a fix loop. Changed context, expired or\nunverifiable checkpoints, and unsupported deltas fall back to full review. Never fabricate a checkpoint.\nFor a deliberately fresh assessment use `--full` (confirm support with `--help`). It controls scope,\nnot depth; it is not needed on every fix. Changing the requested depth mode invalidates compatible\ncheckpoint coverage. Auto does not promise a fixed effective tier; rely on returned analysis/coverage.\nOlder engines omit these fields: use their findings and coverage without claiming reuse.\nPrefer `meta.run.passes` for actual outcomes; legacy `meta.reviewers` describes configured dimensions. Report failed/skipped components and missing metadata; reuse has no new execution.\n\n## Attach coding-session context\n\nUse `--ticket <full-url>` for fetchable ticket context; a bare key is only detected metadata.\nUse `.qodo/session-context.json` at the repo root for ambient context, or `--context-file <path>`\nto override it (`-` reads JSON from stdin). Capture context as it emerges and refresh before review:\n\n```json\n{\n  \"decisions\": [\"The user selected optimistic locking to avoid contention.\"],\n  \"notes\": \"src/orders.ts:updateOrder enforces the version check. Order tests passed; production contention was not tested.\",\n  \"recent_work\": [\"Added optimistic locking; this round includes new behavior.\"]\n}\n```\n\n**Decisions:** Record actual choices and known rationale in natural language. Identify explicit\nuser requirements, user-selected/approved options, and coding-agent choices. A user-selected agent\nproposal is user-selected. Include a source/quote when useful;\nno fixed source tags are required. Leave unknown ownership/rationale explicit; never invent it.\nPut undecided proposals in notes.\n\n**Notes:** Include evidence that could change whether a concern is valid: expected behavior,\nscope, requirements/non-goals and relevant spec text; runtime/callers/reachability/input sources,\nconcurrency/time limits and where enforced; existing guards/exception handling/tests, including\nunchanged files; external contracts/versions and companion changes with actual delivery state.\nCite files/functions. Separate verified constraints from assumptions. Report checks actually run,\nresults, skips/failures, untested paths, limitations and unresolved questions; refresh stale claims.\nThe reviewer cannot see the coding chat. Include relevant source text; links do not prove fetching.\nThe flow owns stored Qodo findings/statuses/dismissal rationale. Add new evidence, changed circumstances\nor external feedback when useful; do not reconstruct that inventory. Reviewers assess code independently.\n\n**Recent work:** Before each new submission, describe changes since the previous review of this\nbranch/worktree, including fixes AND new capabilities/interface changes. Small diffs do not imply\nfixes-only. Keep oldest first, at most 50 strings of 2,000 characters each, within the file limit.\nThis feeds the fix-loop intent judge, stays out of reviewer notes/profile hash, and alone does not\ninvalidate reuse. Eligibility still needs prior review/fix evidence; missing text, unclear verdicts\nor judge failure retain otherwise eligible narrowing; only `new_behavior` exits it. Keep it separate.\n\n**Compatibility and limits:** `summary` remains accepted. Check `qodo review --help`; older CLIs\nuse `summary` for notes, keeping decisions/recent_work. For MCP, use notes only if the live schema\nadvertises it. New producers normalize notes to summary; differing values retain summary then notes\nwith a blank line, identical values once. The normalized narrative must fit the existing limit.\nThe CLI accepts 64 KB total, 50 decisions, and 4,000 characters for narrative/each decision.\nOversize input fails; preserve relevant detail and report delivery gaps, never silently omit it.\nEngine author-note caps still apply; expanded budgets/storage are separate. Never include secrets.\n\nOptional `context_refs` are merged/deduped; labels describe data, not instructions. `ticket` supplies\nticket context; `spec` goes to Requirements Gap. `code_dependency` adds repo/branch/PR links to the\nlength-capped description; generic/unknown kinds remain deferred. Cross-repo routing, when enabled,\nonly selects supplied candidates; refs neither discover repos nor enable review. Provider behavior\nmatches Git review. Check `meta.context.spec`; code dependencies have no consumption receipt.\nDo not infer fetch/use/merge/release/deployment from refs. See [context examples](references/review-turn-context.md).\n\n## Present the review result\n\nAfter reading the completed result, explain each finding as **practical impact → assessment\nusing the code and coding-session context → your decision and recommended action**.\nCredit Qodo naturally once for the concerns its review surfaced. You own the final technical\nassessment: integrate expert review input with the user's intent, decisions, and constraints.\nExplain what could happen, under which conditions, and which behavior is affected; connect that\nimpact to the change the user requested. Do not invent production conditions or affected users.\nFor example: “Qodo identified [risk]. Given our decision to [intent/constraint] and [code\nevidence], I recommend [action] because [reason].” Adapt the wording to the actual evidence.\n\nKeep each issue's explanation coherent, cite supporting code, and preserve its reference and\nreported category/level separately from your recommendation. Group overlapping findings only\nwhen all references remain visible and individually selectable. Use short impact-based titles\nor lists when useful; no branded headings, emoji banners, slogans, footers, or repeated summaries.\nReport only known counts and coverage. Lead with material skipped/failed reviewers or incomplete\ncoverage; zero findings alone is not a clean verdict. A complete review with no findings can be\none sentence. For gated/failed runs, report the actual limitation rather than a completed result.\n\n## Act on the findings\n\nIndependently evaluate every finding and own its disposition and rationale: **fix** a supported\nissue (your fix may differ from Qodo's suggestion), **dismiss** an unsupported concern with code\nevidence, or **investigate** uncertainty by naming the check needed. A session decision supports\ndismissal only when the code enforces its assumptions. Keep the tone collaborative and factual;\ndo not routinely qualify Qodo's capability or turn a wrong finding into a broader judgment.\nYour technical recommendation does not grant permission; apply the user's existing scope below.\n\n**Report-only.** For an explicit request to review without changes, return the assessment and stop;\ndo not solicit edit approval.\n\n**Missing edit authority.** If the intended fix scope is ambiguous, use the assessment above for every finding, keeping its\n`[category/level]` and your recommendation, then ask **in a single prompt** which findings to apply. Use whatever the\nhost gives you: a multi-select if it has one (Claude Code's `AskUserQuestion`, say), otherwise a\nnumbered list and \"reply with the numbers to apply\". One prompt either way — don't ask per finding.\n**Nothing is pre-selected.** Mark which ones you recommend, but the user must actively choose: this\nprompt is the last thing standing between a finding and an edit, so a bare Enter must apply nothing.\nApply only what the user picks (edit as normal, matching the surrounding style); report the rest as\nskipped with your reason. Do not edit any code before the user has chosen.\n\n**Authorized fixes.** `autofix`, an explicit request to fix findings, or existing implementation\nauthority covering the necessary correction permits fixes within that scope. State the assessment\nand apply supported fixes without asking again. A review-only request grants no edit authority;\nask once if the intended scope is ambiguous. Preserve narrower user constraints. Fix authority\ndoes not authorize stored dismissals, pushes, or unrelated changes. Report applied and skipped fixes.\n\nWhen the user explicitly authorizes declining a local finding, follow\n[Record local triage](references/local-triage.md) to persist the decision. A conversational\n\"skip\" alone is not a stored dismissal and must not be reported as one.\nOn MCP, use the live `pr-review-dismiss` schema with finding IDs and `local_review_id` from that completed review, an authorized reason and explanation, and a stable `idempotency_key` for the batch; read back each stored outcome. The reference's CLI commands apply only to the CLI path.\n\nAfter a batch of authorized fixes, verify and re-review changed work using the lifecycle policy above.\nAssess outstanding findings and coverage before calling the result clean; stop an unproductive loop.\nCommit/push per the user's workflow — ask before pushing unless they've told you to.\n\n## Recover a review\n\nFor an accepted async run, collect by operation ID. On a status transport error, retry once after the returned delay (or 15 seconds).\nIf collection still fails, preserve the ID and report the gap; never resubmit just to poll. On a terminal failure, correct a\nrecoverable cause and retry once with the same mode and context. Stop on entitlement, auth, permission, rate-limit, or further failure; report expired results and coverage gaps.\n\nOn `repo_not_connected`, `MT-REPO-NO-CREDENTIAL`, or “could not obtain repository credentials”, inspect `origin` without exposing URL credentials; an SSH alias may differ from the connected host.\nUse a known exact repository `full_name` (self-hosted names may include a host); Codebase Wisdom suggestions do not prove connectivity.\nConfirm `qodo review --help` supports `--repo`. If automatic retries are forbidden, stop and get explicit user approval for the corrected command.\nRetry the original submission once with `--repo <full_name>`, preserving all other flags; collect a new async operation ID if applicable.\nIf the identity is uncertain or the retry fails, stop and report; ask an admin to check Git integration rather than assert disconnection.\n\nFor connected CLI execution, keep the process alive throughout the review; a killed client can\ncause server cancellation after a short grace period. If the host cannot sustain it, use async\ninstead of repeated timeouts. Use [connected progress](references/connected-progress.md) to\nbackground a connected run while retaining status.\n\n**Concurrent reviews can complete independently.** For the same owner/repository/branch, only the\nnewest checkpoint run can publish finding updates; an older result may report `superseded`.\n\nDistinguish a killed client, server cancellation after connection loss, a missing `task.done`\nafter a dropped stream, and a backend `review failed: <detail>` response. Read the actual\nfailure and retained-result hint before choosing recovery; do not infer a size or complexity\nlimit from a connection failure.\n\nFor the first three, collect any retained result using the CLI's recovery hint before submitting again.\nIf the run is confirmed canceled or unrecoverable, retry at most once with uninterrupted execution\nand the same selected depth/context. A pending run is not a reason to restart. Further failure means\nreporting incomplete review, not looping, dropping context or downgrading depth to obtain a result.\n\n## If the run is gated: closed preview\n\n`qodo review` is currently in **closed preview** — the server rejects runs from organizations that\naren't enrolled. A gated run exits non-zero with a stable machine-readable error: `--json` emits\n`{\"error\": {\"code\": \"closed_preview\", \"message\": ..., \"hint\": ...}}`; without `--json` the same\nmessage and hint print as prose.\n\nOn `closed_preview`:\n\n1. **Surface the `message` and `hint` to the user unchanged** (don't paraphrase or truncate;\n   the `--json` payload carries them verbatim, while the CLI's prose output strips terminal\n   control characters), then\n2. **STOP.** The gate is an entitlement, not a transient fault — retrying, backing off, watching,\n   or looping **cannot** succeed until the user's organization is enrolled. Do not re-run\n   `qodo review` unless the user says enrollment happened (after enrollment, access activates\n   within ~10 minutes; no re-login needed).\n\nOnly the review itself is gated — auth (`qodo read whoami`) and the other qodo commands are unaffected.\n\n## Configuration\n\nUse `--fast --async --json` for coding checkpoints, auto for ordinary final review,\nand `--deep` only under the stated exceptions. Use `--json --progress` for connected progress and\nthe resolved merge-base SHA as `--base`. Stamp exact skill/version/distribution provenance\non the first Qodo call after the unadorned version probe and keep session context out of the reviewed diff.\n\n## Error Handling\n\nRead the structured result after non-zero exits. Follow bounded recovery; preserve context and authority.\n\n## Guardrails\n\n- **Local scope.** Review coding milestones and local work before PR/update or completed-work handoff.\n  Use `qodo-review-resolver` for findings already posted on a PR; avoid duplicate unchanged reviews.\n- **No forge writes.** `qodo review` reads your local diff and returns findings; it never pushes,\n  comments, or opens a PR. Resolving a finding means editing code, not posting anywhere.\n- **The base must be pushed;** your local work need not be. New/untracked files are reviewed by\n  default; secrets/binaries/oversized/gitignored files are filtered and reported.\n- **Don't guess creds or the base** — resolve auth first, then pass the intended target's merge-base\n  SHA as `--base`, unless the user explicitly requests an exact baseline.\n- **Collect every run.** Background connected runs or use async; preserve recovery handles.\n  A superseded result does not advance the incremental baseline or certify current code.\n- **Never strip context to beat the clock.** Dropping `--context-file` doesn't make a run faster —\n  it just buys a worse review. Give it time; choose depth by lifecycle, never by timeout pressure.\n- An `MT-TOOL-LOOP` or `MT-RATE-LIMITED` error means stop/back off and change approach, not retry.\n- A `closed_preview` error means the org isn't enrolled in the preview — surface message + hint to\n  the user and stop; never retry or loop on it (see \"If the run is gated\" above).\n\nAfter authorized fixes, report what changed, how it was verified, and what remains with reasons.\n"
}