SKILL.md
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). 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.)
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). 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.)