Qodo

View saved version →

---
name: qodo-codebase-wisdom
description: Understand how code works, how a change was done before, and which repos are coupled — to answer a question, plan a code change, debug a regression, or scope a fix, using Qodo managed tools through MCP or the CLI. Use when a task needs to understand a codebase, its history, or how its repos relate — especially for a repo you don't have checked out or work spanning repos — "how does X work", "where is X defined", "who changed X", "explain this service", "plan the change for X", "what would changing X affect", "which repos depend on X", "why did X regress / when did it break", "has this been fixed before", "how did we solve X".
owner: Qodo
metadata:
  vendor: qodo
  version: "1.1.7"
  recommended: "true"
  package: "qodo"
  distribution: "marketplace"
  instruction_mode: "embedded"
---

# Codebase Wisdom

## Description

Use Qodo managed tools to learn how code works, how a change was done before, and how repos
are coupled — then hand back **cited findings**. This feeds answering a question, planning
a change, debugging a regression, or scoping a fix. It reaches repos you don't have on disk
and spans repo boundaries. You drive qodo's **read** tools only; you never post to the forge.

## Prerequisites

- The required tools are available through a connected QAR managed-tools MCP server or the Qodo CLI.
- The workspace exposes the required read-only Codebase, pull-request, or cross-repo tools.
- The current provider-owned Qodo skill package is loaded in this agent session.

## Instructions

### Choose the execution path

Use the host's connected QAR managed-tools MCP tools when the required read capability is
available; otherwise use the CLI instructions below. Do not require a CLI version probe,
`qodo login`, or a CLI catalog refresh on the MCP path. A connected MCP server has already
handled transport authentication; a missing tool or `MT-AUTH-FORBIDDEN` is a capability or
authorization failure, not a reason to log in through the CLI. Do not silently switch paths
after an auth or permission denial.

On MCP, use the tool descriptions, `inputSchema`, and `readOnlyHint` supplied by the host.
Call only read-only tools. Representative wire names are `litegit-search-repos`,
`litegit-grep`, `litegit-read-file`, `pull-request-similar`, and
`cross-repo-relations`; resolve the actual names and arguments from the connected catalog.
Pass explicit `repo` when needed: MCP does not infer the local Git origin like the CLI.
Check `isError` before using `structuredContent`; preserve typed errors and incomplete or
truncated results. If a call becomes an MCP Task, collect its terminal result before drawing
a conclusion. A missing MCP capability may use an already authorized CLI path for the same
deployment; do not treat different accounts or tenants as interchangeable.

The version, identity, help, command, and refresh steps below apply only to the CLI path.

At investigation start and when moving into implementation, identify the missing context:

- Use Qodo to discover unfamiliar code, prior solutions, historical rationale, and relationships
  across repositories, even when the repositories are available locally.
- Use local tools for exact branch/worktree state, uncommitted changes, edits, and tests.
- Reuse an earlier investigation when it covers the current scope and revisions. Briefly name
  the evidence being reused; refresh the relevant context when scope, dependencies, or evidence
  changes. Do not repeat remote reads solely to demonstrate skill use.

When context is missing, resolve a concrete question through the appropriate tool group below. Connect
retrieved evidence to the answer or implementation decision. Version, identity, and catalog
checks establish readiness; they are not codebase context retrieval.

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

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 4 — file references are metadata, not package contents.

View saved version →

---
name: qodo-review
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.
owner: Qodo
metadata:
  vendor: qodo
  version: "1.10.11"
  recommended: "true"
  package: "qodo"
  distribution: "marketplace"
  instruction_mode: "embedded"
---

# Local Review

## Description

Review **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.

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

## Prerequisites

- An authenticated Qodo CLI is available, or a connected QAR MCP server and a tested local input collector are available; review capability is enabled.
- The comparison base exists on the remote; local changes and context need not be pushed.
- The coding-session context and any ticket or design references are ready to attach.

## Choose when and how deeply to review

| Situation | Selection |
|---|---|
| A coherent milestone during substantive coding | `--fast --async`: light checkpoint; continue useful coding and collect the result. |
| 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. |
| 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. |

Automatic coding checkpoints always use `--fast`. A deliberate deep review can happen earlier when
one of the exceptions above applies. A request such as "examine subtle races thoroughly" can justify
it without the word "deep"; generic "review" or "double-check" does not. Identify concrete impact,
such as shared authorization, a destructive migration, or a contract used by multiple services.
Diff size, session length, PR readiness, or a security-related filename alone do not justify deep.

With **no flag**, the CLI omits depth and the reviewer/deployment selects it. Auto can select deep;
it is not guaranteed standard and does not impose a spending cap. There is no `--standard` flag.
`--fast` and `--deep` are mutually exclusive; depth is selected anew for each invocation.

## Checkpoints and final handoff

- Review a completed, testable slice when its feedback can guide the remaining work. Do not review
  unfinished exploration, every edit, trivial changes automatically, or simply because time passed.
  Respect the user's review scope and budget. A pause for a question or approval is not a final handoff.
- Keep at most one automatic checkpoint active per task. Retain its operation ID, submitted scope
  and snapshot/context association in the task's existing state. Poll status at natural pauses while
  doing useful work; do not launch another review to check progress or re-review unchanged inputs.
- Collect every submitted result within its retention window. Recheck findings against current code
  before acting: the working tree may have changed. A superseded result cannot certify newer work.
  Use the existing CLI lifecycle; no separate sub-agent or scheduler is required.
- Before final review, collect the outstanding checkpoint and reconcile its findings. Review the
  full intended change with auto, or justified deep, rather than handing off on a light checkpoint.
  Remove temporary path restrictions that

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 8 — file references are metadata, not package contents.

View saved version →

---
name: qodo-review-notes
description: Find and maintain Development Track Notes and PR Review Notes through Qodo tools. Use at task intake or when resuming a development effort, before opening a PR, after opening it to bind its notes, or when asked to read or edit reviewer context. Tracks connect issues, repositories and PRs; PR notes explain a specific change. This skill does not review code or open a PR.
owner: Qodo
metadata:
  vendor: qodo
  version: "1.0.2"
  recommended: "true"
  package: "qodo"
  distribution: "marketplace"
  instruction_mode: "embedded"
---

# Development Tracks and PR Review Notes

## Description

Keep the reasoning a reviewer needs in the platform, where other coding sessions and humans can
find it. Development Track Notes explain the overall effort across issues, repositories and PRs.
PR Review Notes explain one change and link to a track explicitly.

## Prerequisites

Use an authenticated Qodo connection to the intended deployment and workspace. Notes tools must
be available in the live catalog. For CLI use, require Qodo CLI **2.0.0 or newer** and the
PR commands' `localGitCapture` capability. A trusted MCP connection can supply the same operations.

## Instructions

Discover the available tools, select the track explicitly, maintain revision-safe notes, publish
the existing source HEAD before PR creation, then bind the returned notes ID after opening.

## Handle a skill update notice

Treat `QODO_NOTICE` updates as passive. Continue the task and mention each notice at most once;
updated instructions load next session. For a requested update, follow
the manual maintenance procedure below without changing the organization's update origin.

## Execution

- MCP: use live schema arguments; skip CLI shell steps.
- CLI: use complete UTF-8 files without a BOM (`--args-file` for tools, `--context-file` for reviews); examples are POSIX.
- 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.

## Choose the available tools

Use a trusted connected Qodo MCP server when available, otherwise the authenticated `qodo` CLI.
Discover the live schemas; the Tool access section below explains both transports and write
idempotency. Skills do not handle credentials, make HTTP requests, or use another account.
Read/discover without asking. Honor the host's write gate and the user's existing authorization
for note maintenance; a request to read or review notes alone does not authorize editing them.

When using the CLI, check `qodo --version` before discovering its live notes commands:

```sh
qodo --version
qodo read whoami --json --skill qodo-review-notes --skill-version 1.0.2 --distribution marketplace --host codex
qodo read tools review-notes --json
qodo tools help review-notes --json
```

If the version is below the minimum or cannot be parsed, stop authenticated CLI calls and explain
the update needed. Before offering an update, check only whether `QODO_UPDATE_BASE_URL` is set;
never print its value. If set, it overrides the recorded source: ask the user to resolve that
override before proceeding, without changing it yourself. Automatic updates stay within a major.
For a runtime below 2.x or an unparseable version, explain the prerequisite and ask once before
explicit 2.x installation with a checksum-pinned installer supplied by Qodo or the organization.
Reuse covering installation authorization, preserve the recorded origin and never invent a digest.
For an eligible in-major update, offer `qodo update` at that origin and honor existing update
authorization, otherwise ask once. After installation or update, rerun the unadorned version
probe before `whoami` or tool discovery.
If no update is authorized, stop this CLI path; trusted MCP remains available when configured.
Follow the Tool access recovery rules for other failures.

The platform scopes records to the authenticated w

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 3 — file references are metadata, not package contents.

View saved version →

---
name: qodo-review-resolver
description: Read or resolve a pull request's Qodo review using Qodo managed tools through MCP or the 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.9"
  recommended: "true"
  package: "qodo"
  distribution: "marketplace"
  instruction_mode: "embedded"
arguments:
  - name: autofix
    description: Optional shorthand for authorizing supported fixes. An explicit fix request or covering implementation authority also permits those fixes without another prompt.
    optional: true
---

# Read & Resolve Findings

## Description

Use Qodo managed tools 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). Apply supported fixes when the user has authorized them; otherwise present your assessment
for selection. Run once (report + authorized fixes) or as a watch loop (resolve →
let Qodo re-review the new commit → repeat until clean). When separately authorized, **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

- A connected QAR managed-tools MCP server or authenticated Qodo CLI exposes review-session tools.
- The exact PR URL and its current head SHA can be resolved without scraping review comments.
- Any finding-status write has explicit user authorization; code-fix authority or `autofix` alone does not cover 

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 4 — file references are metadata, not package contents.

View saved version →

---
name: qodo-setup
description: Set up Qodo in a coding agent — install the CLI, sign in, and verify tools. Use after plugin installation, on setup requests, or when a Qodo skill finds a missing CLI or login.
owner: Qodo
metadata:
  vendor: qodo
  version: "1.0.12"
  recommended: "true"
  package: "qodo"
  distribution: "marketplace"
  instruction_mode: "embedded"
---

# Set up Qodo

## Description

Verify the available Qodo path. Skill installation does not prove account or tool access.

## Prerequisites

A shell for CLI setup or a host-connected QAR MCP server. Never handle credentials.

## Instructions

### Connected MCP path

Inspect connected QAR tool schemas and annotations. With harmless input, call one
read-only tool; catalog visibility does not prove read access. Check `isError` before
`structuredContent`; an execution error is not readiness. A read cannot prove write
authorization: report writes as unverified until a user-authorized action. Never make
a test write. The host and QAR own MCP auth. Report missing tools, `MT-AUTH-FORBIDDEN`,
and connection errors as MCP access issues; never ask for an API key. For MCP-only setup,
report the verified scope and hand off here. Skip every CLI step below. Continue only if CLI access was
requested or is needed for local collection, using the same deployment.

Resolve `references/...` links relative to this installed `SKILL.md` directory.
Runtime/login setup does not authorize enterprise installation or maintenance.
For requested enterprise installs, disclose packages and maintenance before approval;
preserve opt-outs, edits, owners and optional-package choices.

### 1. Find or install the runtime

In PowerShell, resolve the verified native/Node invocation in [runtime.md](references/runtime.md)
first; `qodo` below represents that invocation. On POSIX, probe PATH directly:

```sh
qodo --version
```

If missing on POSIX, try `"${QODO_HOME:-$HOME/.qodo}/bin/qodo" --version`.
For a missing, old or unparseable runtime, follow the reference. Setup requests cover installation subject
to host approvals; plugin installation alone does not. Retain the selected deployment.

Keep the executable as `<qodo>`. Require Qodo CLI **2.0.0 or newer** before authentication.

### 2. Connect

Run:

```sh
<qodo> read whoami --json --skill qodo-setup --skill-version 1.0.12 --distribution marketplace --host codex
```

Reuse a successful identity check. On failure, read
[authentication.md](references/authentication.md) before choosing login.

For Cloud, run `<qodo> login` when signed out. For customer deployments, preserve the
documented login endpoint; never fall back to Cloud. Wait for login, then recheck identity.

Reuse the successful execution context, requesting each required host approval. A diagnostic
approval is not blanket permission. Stop on cancellation or denied permission.

### 3. Verify tools

Only after identity succeeds, run:

```sh
<qodo> tools --refresh --json --skill qodo-setup --skill-version 1.0.12 --distribution marketplace --host codex
```

Require a usable catalog and the task's capability; unrelated tools do not establish access.
If refresh fails, report that sign-in succeeded but tools are unavailable, with the exact error
and `<qodo> tools --refresh` as the retry. Do not log in again for a catalog failure.

## Configuration

The CLI owns credentials, transport and runtime updates; the package's
lifecycle owner updates skills. For `QODO_NOTICE` updates or repeated Kiro read approvals,
read [host-recovery.md](references/host-recovery.md) only when encountered.

## Error Handling

Give the actual error and one next action. Never report readiness after a failed
identity, canceled login or unavailable catalog. Never disable the keychain, copy credentials,
change host permission files, or offer unrestricted command approvals to make setup pass.

## 4. Hand off

Confirm Qodo connection and relevant tool readiness, then return to the authorized task.
Readiness does not prove a later

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 5 — file references are metadata, not package contents.