
Qodo Pr Resolver
Resolve review feedback on Gerrit changes using Qodo’s PR resolver patterns—detection, auth, and unified review API instead of GitHub-style pull requests.
Overview
qodo-pr-resolver is an agent skill most often used in Ship (also Build git workflows) that resolves Gerrit change review comments via Qodo-tagged API calls and repo detection heuristics.
Install
npx skills add https://github.com/qodo-ai/qodo-skills --skill qodo-pr-resolverWhat is this skill?
- Gerrit provider guide: Change-Id commits, refs/for pushes, not branch-based PRs
- Multi-signal detection via .gitreview, SSH port 29418, and googlesource.com remotes
- curl + HTTP Basic Auth workflow with )]}' JSON prefix stripping on all API responses
- Qodo comments use tag autogenerated:qodo on human-style review payloads
- Unified POST /revisions/current/review endpoint for comment operations
- Single unified POST /revisions/current/review endpoint for Gerrit comment operations
- API responses require stripping )]}' prefix before JSON parse
Adoption & trust: 2.1k installs on skills.sh; 37 GitHub stars; 1/3 security scanners passed (skills.sh audits).
What problem does it solve?
You use Gerrit for review but generic PR-resolver skills assume GitHub/GitLab APIs and break on Change-Ids, refs/for pushes, and Gerrit’s JSON prefix.
Who is it for?
Small teams and solo maintainers on Gerrit (including Google-hosted) who already run Qodo and want agent-driven comment resolution on open changes.
Skip if: Pure GitHub-only repos without Gerrit remotes, or reviewers who forbid autogenerated review tags on their server policy.
When should I use this skill?
PR resolver runs after GitHub/GitLab/Bitbucket/Azure detection and Gerrit signals (.gitreview, port 29418, googlesource.com) match.
What do I get? / Deliverables
Your agent detects Gerrit correctly, authenticates with Basic Auth, strips Gerrit JSON guards, and posts or resolves Qodo-tagged comments through the unified review endpoint.
- Resolved or drafted Gerrit review comment threads
- Provider-accurate Gerrit API calls with parsed JSON responses
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Ship because the skill operationalizes code review and change-resolution on Gerrit before merge, alongside other Qodo PR resolver providers. Review subphase matches posting and addressing review comments via Gerrit’s single review endpoint and tagged Qodo autogenerated comments.
Where it fits
Triage open Gerrit feedback on your HEAD revision and draft responses before maintainers re-review.
Validate .gitreview host/project parsing in a monorepo you just cloned from googlesource.com.
Clear lingering review threads on long-lived changes after production hotfix branches.
How it compares
Gerrit-specific companion to generic PR resolver flows—curl and Change-Id semantics, not GitHub gh CLI.
Common Questions / FAQ
Who is qodo-pr-resolver for?
Developers using Qodo skills with Gerrit-hosted repos who need Change-Id-aware review automation from Claude Code, Cursor, or Codex.
When should I use qodo-pr-resolver?
At Ship during code review when detection finds .gitreview or a 29418/googlesource remote; at Build when wiring CI review bots before release.
Is qodo-pr-resolver safe to install?
It requires Gerrit credentials and git push access—review the Security Audits panel on this page and scope passwords to review-only accounts where possible.
SKILL.md
READMESKILL.md - Qodo Pr Resolver
# Gerrit Provider Reference Gerrit uses **Changes** (not Pull Requests). All API interactions use `curl` + HTTP Basic Auth — there is no official Gerrit CLI. **Key differences from other providers:** - Changes are identified by a `Change-Id` in the commit message (not a branch name) - Push for review: `git push origin HEAD:refs/for/<target-branch>` (not `git push`) - All comment operations go through a **single unified endpoint** (`POST /revisions/current/review`) - Qodo posts as **tagged human comments** with `tag: "autogenerated:qodo"` (not robot comments) - All API responses are prefixed with `)]}'` — must strip before JSON parsing ## Provider Detection Gerrit detection is multi-signal (checked after GitHub/GitLab/Bitbucket/Azure DevOps): 1. **`.gitreview` file** in repo root (strongest signal) — parse `host` and `project` from it 2. **Port `29418`** in SSH remote URL 3. **`googlesource.com`** in remote URL (Google-hosted Gerrit) ```bash # Check for .gitreview file if [ -f .gitreview ]; then GERRIT_HOST=$(git config -f .gitreview gerrit.host 2>/dev/null) GERRIT_PROJECT=$(git config -f .gitreview gerrit.project 2>/dev/null) fi # Check remote URL patterns REMOTE_URL=$(git remote get-url origin) echo "$REMOTE_URL" | grep -qE ':29418/' && echo "Gerrit (SSH)" echo "$REMOTE_URL" | grep -q 'googlesource.com' && echo "Gerrit (Google)" ``` ## Prerequisites ### Authentication HTTP Basic Auth with a password generated from Gerrit's settings page. **Qodo config** (`~/.qodo/config.json`) — store credentials persistently: ```json { "GERRIT_URL": "https://review.example.com", "GERRIT_USERNAME": "your-username", "GERRIT_HTTP_PASSWORD": "your-http-password" } ``` - `GERRIT_URL`: Gerrit instance base URL (always required — there is no default host) - `GERRIT_USERNAME`: Your Gerrit username - `GERRIT_HTTP_PASSWORD`: HTTP password from **Settings → HTTP Credentials** (this is NOT your account password) ### Extract project info from `.gitreview` ```bash GERRIT_PROJECT=$(git config -f .gitreview gerrit.project 2>/dev/null) TARGET_BRANCH=$(git config -f .gitreview gerrit.defaultbranch 2>/dev/null || echo "main") ``` ### Magic JSON prefix All Gerrit REST API responses start with `)]}'` on the first line (XSS protection). Strip it before parsing: ```bash | tail -c +6 | python3 -m json.tool ``` Every `curl` command in this file includes this pipe. ### Verify ```bash curl -s -u "$GERRIT_USERNAME:$GERRIT_HTTP_PASSWORD" \ "$GERRIT_URL/a/accounts/self" | tail -c +6 | python3 -m json.tool ``` **Note:** All authenticated endpoints use the `/a/` prefix in the path. Some Gerrit instances also have an API prefix (e.g. `/r/`) — if `GERRIT_URL` includes it (e.g. `https://git-master.example.com/r`), the full path becomes `/r/a/changes/...`. ## Find Open Change Gerrit has no "source branch" concept. Changes are identified by `Change-Id` from the commit message. ### Extract Change-Id from commit ```bash CHANGE_ID=$(git log -1 --format=%b | grep 'Change-Id:' | sed 's/.*Change-Id: //') ``` ### Query by Change-Id (preferred) ```bash curl -s -u "$GERRIT_USERNAME:$GERRIT_HTTP_PASSWORD" \ "$GERRIT_URL/a/changes/?q=change:$CHANGE_ID+status:open&o=CURRENT_REVISION&o=MESSAGES" \ | tail -c +6 | python3 -m json.tool ``` ### Query by project + owner (fallback) ```bash curl -s -u "$GERRIT_USERNAME:$GERRIT_HTTP_PASSWORD" \ "$GERRIT_URL/a/changes/?q=status:open+project:$GERRIT_PROJECT+owner:self&o=CURRENT_REVISION" \ | tail -c +6 | python3 -m json.tool ``` Response is a JSON array. Key fields: `_number` (change number), `project`, `branch`, `current_revision`. ## Fetch Review Comments Gerrit has **three separate comment endpoints**. Fetch all three. ### Human comments (where Qodo posts) Qodo posts inline comments as **human comments** with `tag: "autogenerated:qodo"`. This is the primary endpoint to check. Filter for Qodo: check `tag` field equals `"autogenerated:qodo"`, or `author.username` matches the Qodo bot user (e.g. `"