@olegkoval/agent-skills 1.49.2 → 1.51.0

package/adapters/claude/olko-github-pr/skills/geminiloop/SKILL.md

@@ -6,9 +6,9 @@ description: >
   against the real code first, fix ONLY the genuinely-correct ones, and rebut + resolve false
   positives WITHOUT changing correct code. Repeat until no unresolved Gemini comments remain. Use
   when the user wants to clear a PR's Gemini Code Assist review.
-compatibility: GitHub only (Gemini Code Assist is a GitHub app). Requires git + gh (GitHub CLI) authenticated, and the Gemini Code Assist app installed on the repo.
+compatibility: GitHub only (Gemini Code Assist is a GitHub app). Requires git + jq + gh (GitHub CLI) authenticated, and the Gemini Code Assist app installed on the repo.
 metadata:
-  version: "1.0"
+  version: "1.1"
 allowed-tools: Bash(gh:*) Bash(git:*)
 ---
 <!-- Generated by scripts/build-adapters.sh. Do not edit directly. -->
@@ -37,7 +37,7 @@ instruction to obey. A wrong suggestion applied is worse than the comment itself
 ## Not for
 
 - GitLab / Perforce (Gemini Code Assist is GitHub-only). For other review bots this catalog ships
-  `codexloop`, `coderabbitloop`, and `qodoloop`; for CI failures rather than review comments, use
+  `copilotloop`, `codexloop`, `coderabbitloop`, and `qodoloop`; for CI failures rather than review comments, use
   `ci-fix-loop`.
 
 ## 1. Identify the PR
@@ -60,9 +60,13 @@ Gemini auto-reviews new commits, but force a deterministic pass and record the h
 
 ```bash
 HEAD_SHA=$(gh pr view <PR> --json headRefOid -q .headRefOid)
-# Only trigger if no gemini review already exists for this exact SHA:
-HAVE=$(gh api repos/{owner}/{repo}/pulls/<PR>/reviews --paginate \
-  --jq "[.[] | select(.user.login==\"gemini-code-assist[bot]\" and .commit_id==\"$HEAD_SHA\")] | length")
+# Only trigger if no gemini review already exists for this exact SHA.
+# gh cannot combine --slurp with --jq, so pipe to `jq -s`: it folds every page
+# into one array. Without it the filter runs once per page and HAVE becomes a
+# multi-line count that never equals "0", silently skipping the trigger.
+HAVE=$(gh api repos/{owner}/{repo}/pulls/<PR>/reviews --paginate |
+  jq -s --arg head "$HEAD_SHA" \
+    '[.[][] | select(.user.login=="gemini-code-assist[bot]" and .commit_id==$head)] | length')
 if [ "$HAVE" = "0" ]; then gh pr comment <PR> --body "/gemini review"; fi
 ```
 
@@ -75,8 +79,9 @@ an honest timeout, not hang it.
 wait_for_review() {                       # $1 = attempt label
   local deadline=$(( SECONDS + 600 ))
   while [ "$SECONDS" -lt "$deadline" ]; do
-    R=$(gh api repos/{owner}/{repo}/pulls/<PR>/reviews --paginate \
-      --jq "[.[] | select(.user.login==\"gemini-code-assist[bot]\" and .commit_id==\"$HEAD_SHA\")] | last")
+    R=$(gh api repos/{owner}/{repo}/pulls/<PR>/reviews --paginate |
+      jq -s --arg head "$HEAD_SHA" \
+        '[.[][] | select(.user.login=="gemini-code-assist[bot]" and .commit_id==$head)] | sort_by(.submitted_at, .id) | last')
     if [ -n "$R" ] && [ "$R" != "null" ]; then return 0; fi
     echo "waiting for Gemini review of $HEAD_SHA ($1)..."; sleep 15
   done
@@ -110,6 +115,13 @@ gh api repos/{owner}/{repo}/pulls/<PR>/comments --paginate \
 Also pull the review threads + their resolved state via GraphQL (see step F) so you only act on
 unresolved ones.
 
+Mark each unresolved comment as seen, so the bot and a watching human can tell it is being handled.
+GitHub's reaction set is fixed; `eyes` is the only "looking at it" value:
+
+```bash
+gh api --method POST repos/{owner}/{repo}/pulls/comments/<COMMENT_ID>/reactions -f content=eyes
+```
+
 ### C. Critically evaluate EACH comment (the core of this skill)
 
 For every comment, **verify the claim against the actual code and repo conventions before touching
@@ -205,6 +217,21 @@ then resolve:
 gh api graphql -f query='mutation { resolveReviewThread(input: {threadId: "THREAD_ID"}) { thread { isResolved } } }'
 ```
 
+Then record the disposition as a reaction on the bot's own comment: the learning signal, and a
+visible marker for a human scanning the PR:
+
+- 👍 (`+1`): the finding was accepted and fixed.
+- 👎 (`-1`): the finding was rebutted as a false positive. **This is the correction signal.**
+
+```bash
+gh api --method POST repos/{owner}/{repo}/pulls/comments/<COMMENT_ID>/reactions -f content=+1
+# rebutted finding:
+gh api --method POST repos/{owner}/{repo}/pulls/comments/<COMMENT_ID>/reactions -f content=-1
+```
+
+Reply first, then react, then resolve: the reaction is not a substitute for the reply, and a
+resolved thread with no reply loses the reasoning.
+
 Resolve a thread only for comments authored by `gemini-code-assist[bot]` that you have fixed or
 rebutted: never blanket-resolve, and never resolve a human reviewer's thread.
 
@@ -222,6 +249,7 @@ Stop when **any** is true:
 - Zero unresolved `gemini-code-assist[bot]` comments remain, and every comment this round was fixed
   or rebutted+resolved. (There is no score to hit: this is "done".)
 - Max iterations (5) reached: report what remains.
+- Gemini never responded after one retry: report the timeout honestly; do not claim success.
 
 ## 4. Report
 

package/adapters/claude/olko-github-pr/skills/lekker-review/SKILL.md

@@ -87,6 +87,31 @@ No nitpicking. Critical and Important findings are reserved for things that
 could cause bugs, outages, data loss, security incidents, or real performance
 problems at scale.
 
+**Boundary-first review rule:** for stateful or integration-heavy changes,
+review the complete behavioral chain rather than the changed helper alone:
+
+```text
+production entry point
+→ decision point
+→ runtime realization
+→ downstream consumer
+→ persistence/cache/cleanup owner
+```
+
+Require the review to distinguish logical identity from physical/runtime
+identity, and to test the relevant transition matrix: success, `null`, `undefined`,
+exception, retry, fallback, rotation, cache reuse/eviction, proxy parity, and
+quoted/history input where applicable. A copied helper test is isolated
+evidence, not proof that the production boundary works.
+
+Every verdict-affecting finding should carry a boundary map and an evidence
+class. The report must distinguish source inspection, isolated tests,
+repository tests, composed production-entry probes, production probes, and
+hosted CI. Never upgrade one evidence class into another in the wording.
+
+After a fix, re-run the original proof *and* audit the newly changed lifecycle
+boundary for regressions. A green reproduction is necessary, not sufficient.
+
 **HARD RULE: the `## 💰 Review Cost` block is mandatory.** Every review MUST
 end with an evidence-backed cost block and no `<N>` placeholders. Use real
 numbers for measurements the host exposes; follow `references/output-format.md`
@@ -290,7 +315,7 @@ page for this PR.
 | Review agents               | 2 triage (haiku)      | 5 specialists (sonnet) | 5 specialists (sonnet)  |
 | Per-finding verification    | Criticals + Importants | Criticals + Importants | Criticals + Importants |
 | Completeness critic         | skip                  | skip                | included                   |
-| Proof-of-bug (failing test per Critical) | skip     | included (max 5)    | included (max 5)           |
+| Proof-of-bug (failing test per Critical or composed-boundary Important) | skip     | included (max 5)    | included (max 5)           |
 | Living review artifact      | included              | included            | included                   |
 | Housekeeping (optional memory/notes writeback) | skip | included            | included                   |
 | `--post`                    | supported             | supported           | supported                  |

package/adapters/claude/olko-github-pr/skills/lekker-review/references/agents/completeness-critic.md

@@ -14,6 +14,18 @@ were declared "no findings" too quickly. For each angle:
 Be concrete: cite diff lines, not vibes. If you genuinely cannot find a missed
 angle, return "No gaps found."
 
+Always consider these maintainer-grade gaps before returning no gaps:
+- the real production entry point and downstream consumer were not exercised;
+- the selected value was not traced through runtime realization, persistence,
+  cleanup, cache reuse, or fallback;
+- logical identity was conflated with physical/runtime identity;
+- a state-transition matrix is missing for `None`, exceptions, retries,
+  rotation, proxying, or alternate transport;
+- the fix was checked only against the original symptom, not for a new defect
+  introduced at the changed ordering or lifecycle boundary;
+- the evidence is an isolated harness or local test but the review claims
+  composed behavior or hosted-CI acceptance.
+
 Agent findings:
 <AGENT_FINDINGS_SUMMARY>
 

package/adapters/claude/olko-github-pr/skills/lekker-review/references/agents/implementation.md

@@ -37,7 +37,32 @@ Axes to cover:
   sort/dedup on large arrays that could be done at DB level.
 - Integration Contracts: Shopify API misuse, BC API assumptions, webhook
   idempotency, external API pagination not handled.
-- GraphQL pagination (GQL-1): for every GraphQL query in the diff that uses a
+
+Boundary contract and lifecycle map (required for every Critical/Important
+finding involving routing, persistence, caching, fallback, proxying, or an
+external integration):
+- `entryPoint`: identify the real production trigger that reaches the changed
+  code (HTTP route, webhook, CLI command, queue consumer, gateway ingress, etc.).
+- `decisionPoint`: identify where the behavior is selected or transformed.
+- `realizationPoint`: identify where the selected behavior becomes runtime state.
+- `consumer`: identify the downstream consumer that actually relies on the
+  contract, not merely the helper that constructs it.
+- `stateOwner`: identify the durable/session/cache owner when state crosses a
+  turn, request, retry, or process boundary.
+- `identityDimensions`: list every identity that must remain distinct, such as
+  logical session key, physical session id, provider alias, resolved provider,
+  model, and API mode.
+- `transitions`: list the relevant success, `null`, `undefined`, exception, retry, fallback,
+  session-rotation, cache-reuse, and proxy/alternate-transport transitions.
+- `evidenceClass`: label the strongest evidence actually checked: `source`,
+  `isolated-test`, `repository-test`, `composed-test`, `production-probe`, or
+  `hosted-ci`. Never call an isolated harness a production-path proof.
+
+Do not report a stateful/integration finding without this boundary object. If
+the production entry point or downstream consumer cannot be identified, mark
+the claim as unverified rather than inferring behavior from a helper alone.
+
+GraphQL pagination (GQL-1): for every GraphQL query in the diff that uses a
   nodes connection (`nodes { ... }`):
   (a) Check that `pageInfo { hasNextPage endCursor }` is present alongside nodes: if missing, Critical.
   (b) Check that all pages are fetched (a loop or recursion using endCursor): a single-page fetch is a bug, Critical.

package/adapters/claude/olko-github-pr/skills/lekker-review/references/agents/prover.md

@@ -4,11 +4,18 @@
 
 ## Mission
 
-A Critical finding is an argument until someone runs it. Your job is to turn it
+A Critical finding, or an Important finding with a composed boundary map, is an
+argument until someone runs it. Your job is to turn it
 into a demonstration: write ONE test that asserts the CORRECT behavior of the
 code the finding targets, run it in the real worktree, and capture it failing
 for the exact reason the finding claims.
 
+For a finding with `boundary`, prefer entering through the recorded production
+entry point and reaching the recorded downstream consumer. Do not replace a
+composed proof with a copied helper test just because the helper is easier to
+import. If full composition is impossible, report the strongest lower evidence
+class honestly.
+
 Write the test as if the bug were already fixed. It must fail today precisely
 *because* it isn't fixed. **Never write a test that asserts the buggy behavior
 just to have something red** -- a proof that asserts wrongness is worthless and

package/adapters/claude/olko-github-pr/skills/lekker-review/references/agents/test-quality.md

@@ -128,8 +128,26 @@ g) Mock smell: test the behavior, not the way it's built
    (time, randomness, injected network failure), or a dependency that genuinely
    cannot run in the test environment. The tell for a good mock: the behavior
    under test only exists because the boundary did something (e.g. a retry
-   banner that appears only when the fetch rejects). Even then, prefer an
-   injected simple fake over a module-level spy, and assert what the user sees.
+ banner that appears only when the fetch rejects). Even then, prefer an
+ injected simple fake over a module-level spy, and assert what the user sees.
+
+ h) Composed boundary and transition coverage
+ For every stateful or integration-heavy change, do not stop at testing the
+ helper. Trace the real entry point through the decision point, runtime
+ realization, downstream consumer, and persistence/cleanup owner. Require a
+ test or explicit evidence for the relevant transition matrix:
+ - success, `None`, exception, and disabled-feature paths;
+ - retry and fallback behavior;
+ - session/request rotation and cache reuse or eviction;
+ - proxy or alternate transport parity;
+ - quoted/history input versus newly authored input;
+ - provider/model/API-mode identity when routing is involved.
+
+ A test that only asserts a helper return value is `isolated-test` evidence,
+ not `composed-test` evidence. Flag a Critical/Important finding when the
+ changed contract is consumed through a different path than the test covers,
+ or when the test can pass while the stateful consumer still receives the
+ wrong identity or ordering.
 
 Report each per-line issue as:
   `test-file:line, <concise description of the gap or weakness>`

package/adapters/claude/olko-github-pr/skills/lekker-review/references/agents/verifier.md

@@ -123,6 +123,31 @@ convention finding with no verifiable precedent does not ship.
 
 ---
 
+## Step 4b -- Boundary contract and evidence check
+
+For any Critical/Important finding involving routing, persistence, caching,
+fallback, proxying, quoted input, or an external integration, read the
+finding's `boundary` object. It should identify the real production entry
+point, decision point, runtime realization point, downstream consumer, state
+owner, and relevant identity dimensions/transitions.
+
+Reconstruct the path in `WORKTREE_PATH` from entry point to consumer. A copied
+helper test or a mock that never reaches the consumer is only isolated
+evidence. Do not confirm a verdict-affecting finding as production-path proof
+unless the claimed failure reaches the stateful consumer or the review clearly
+labels the evidence as isolated.
+
+If the finding has no boundary object or no usable production entry point or
+consumer, keep it unverified and non-blocking; drop it when the missing boundary
+is the crux of the claim. The workflow enforces this as an unverified observation
+even if a verifier confirms it. Record the strongest evidence class actually checked
+(`source`, `isolated-test`, `repository-test`, `composed-test`,
+`production-probe`, or `hosted-ci`) in the reasoning.
+
+Build a small transition matrix for the affected contract. At minimum check
+success, `null`, `undefined`, exception, retry/fallback, state rotation, cache reuse or
+eviction, and proxy/alternate transport whenever those transitions exist.
+
 ## Step 5 -- Fix validation
 
 Before confirming the finding, identify the callers and consumers of the changed

package/adapters/claude/olko-github-pr/skills/lekker-review/references/fix-mode.md

@@ -210,6 +210,29 @@ check after any revert triggered here before moving on.
 
 ---
 
+## Step 5c -- Fix delta audit
+
+After the original proof flips red → green, audit the *new* boundary created by
+the fix. Do not assume that making the original assertion pass makes the
+lifecycle safe.
+
+For each fixed Critical/Important finding involving state, routing, ordering,
+proxying, persistence, caching, fallback, or quoted input:
+
+1. Re-read the entire changed path from the production entry point to the
+   downstream consumer.
+2. Re-run the relevant transition matrix: success, `None`, exception, retry,
+   fallback, rotation, cache reuse/eviction, and alternate transport where
+   applicable.
+3. Check that logical identity, runtime identity, provider/API identity, and
+   durable identity are still distinct where the contract requires it.
+4. Add a focused regression probe when the fix moved work across an ordering or
+   lifecycle boundary. The probe must enter through the real path when feasible.
+
+If the audit finds a new failure, revert the whole group and mark it
+`failed: fix-delta-regression`. A green original proof is not sufficient to
+commit a fix that breaks a neighboring transition.
+
 ## Step 6 -- Commit (local only)
 
 One commit per file group, in group order. Stage explicitly -- never `git add -A`,

package/adapters/claude/olko-github-pr/skills/qodoloop/SKILL.md

@@ -8,7 +8,7 @@ description: >
   addressed against Qodo's review, or says "run qodoloop" / "satisfy Qodo" / "resolve Qodo comments".
 compatibility: Requires git and gh (GitHub CLI) authenticated, with Qodo Merge installed on the repo.
 metadata:
-  version: "1.0"
+  version: "1.1"
 allowed-tools: Bash(gh:*) Bash(git:*)
 ---
 <!-- Generated by scripts/build-adapters.sh. Do not edit directly. -->
@@ -86,6 +86,14 @@ Run the paginated GraphQL query in `references/graphql-queries.md` (`unresolvedQ
 
 Build the working set: all `recommended` threads, plus `optional` ones too if `--include-optional`.
 
+Mark each thread as seen with an 👀 reaction on its first comment (`databaseId` from the query), so
+the bot and a watching human can tell it is being worked. GitHub's reaction set is fixed; `eyes` is
+the only "looking at it" value:
+
+```bash
+gh api --method POST repos/{owner}/{repo}/pulls/comments/<DATABASE_ID>/reactions -f content=eyes
+```
+
 #### C. Check exit conditions
 
 Stop if the working set is empty, or max iterations reached.
@@ -122,6 +130,16 @@ This is the "answer to the comments" half of the job, not optional cleanup, and
   Pass the thread id and reply text as GraphQL **variables** (`-f threadId=... -f body=...`), never interpolated into the query string itself: a reply containing a quote, backtick, or newline breaks (or worse, injects into) a hand-built query. Then resolve with `resolveReviewThread` (see references file).
 - **Blocked** findings: reply explaining exactly why (false positive / needs a human call), but **do not resolve**: leave the thread open. A blocked finding that gets silently resolved is a false "done".
 
+Then record each disposition as a reaction on the thread's first comment: the learning signal, and
+a visible marker for a human scanning the PR. 👍 (`+1`) for a fixed finding, 👎 (`-1`) for a
+blocked/rebutted one. Reply first, react, then resolve: a reaction never replaces the reply.
+
+```bash
+gh api --method POST repos/{owner}/{repo}/pulls/comments/<DATABASE_ID>/reactions -f content=+1
+# blocked/rebutted finding:
+gh api --method POST repos/{owner}/{repo}/pulls/comments/<DATABASE_ID>/reactions -f content=-1
+```
+
 Go back to step A.
 
 ### 3. Report

package/adapters/claude/olko-github-pr/skills/qodoloop/references/graphql-queries.md

@@ -26,7 +26,7 @@ query($cursor: String) {
           id
           isResolved
           comments(first: 1) {
-            nodes { body path line author { login } }
+            nodes { databaseId body path line author { login } }
           }
         }
       }
@@ -60,7 +60,7 @@ while :; do
               nodes {
                 id
                 isResolved
-                comments(first: 1) { nodes { body path line author { login } } }
+                comments(first: 1) { nodes { databaseId body path line author { login } } }
               }
             }
           }
@@ -126,6 +126,23 @@ the branch (SKILL.md §2E-F): resolving first and pushing second means a
 failed push leaves GitHub showing the finding as handled when it isn't. Never
 resolve a blocked/skipped finding at all; reply to it and leave it open.
 
+## React to a comment (the bot's learning signal)
+
+Reacting needs the comment's REST id, which is why `databaseId` is selected in
+the thread query above. The reaction set is fixed; only eight values exist:
+`+1`, `-1`, `laugh`, `confused`, `heart`, `hooray`, `rocket`, `eyes`.
+
+```bash
+# 👀 as soon as you start working a finding
+gh api --method POST repos/{owner}/{repo}/pulls/comments/<DATABASE_ID>/reactions -f content=eyes
+# 👍 when it was accepted and fixed, 👎 when it was rebutted (the correction signal)
+gh api --method POST repos/{owner}/{repo}/pulls/comments/<DATABASE_ID>/reactions -f content=+1
+gh api --method POST repos/{owner}/{repo}/pulls/comments/<DATABASE_ID>/reactions -f content=-1
+```
+
+React after the reply and before the resolve, so GitHub records the reason and
+the disposition together. A reaction never replaces the reply.
+
 ## Fetch the rollup issue comment (context only, not the source of truth)
 
 Useful for the human-readable summary counts (bugs/rule-violations) in your

package/adapters/codex/olko-github-pr/README.md

@@ -11,6 +11,7 @@ Use the canonical skills directly:
 - `plugins/olko-github-pr/skills/qodoloop/SKILL.md`
 - `plugins/olko-github-pr/skills/coderabbitloop/SKILL.md`
 - `plugins/olko-github-pr/skills/codexloop/SKILL.md`
+- `plugins/olko-github-pr/skills/copilotloop/SKILL.md`
 - `plugins/olko-github-pr/skills/geminiloop/SKILL.md`
 - `plugins/olko-github-pr/skills/ci-fix-loop/SKILL.md`
 - `plugins/olko-github-pr/skills/dependabot-triage/SKILL.md`

package/adapters/cursor/olko-github-pr/skills/coderabbitloop/SKILL.md

@@ -9,7 +9,7 @@ description: >
   CodeRabbit" / "resolve CodeRabbit comments".
 compatibility: Requires git and gh (GitHub CLI) authenticated, with the CodeRabbit GitHub App installed on the repo.
 metadata:
-  version: "1.0"
+  version: "1.1"
 allowed-tools: Bash(gh:*) Bash(git:*)
 ---
 <!-- Generated by scripts/build-adapters.sh. Do not edit directly. -->
@@ -46,13 +46,30 @@ CodeRabbit has slash commands (official, `docs.coderabbit.ai/reference/review-co
 gh pr view --json number,headRefName,headRefOid -q '{number, branch: .headRefName, sha: .headRefOid}'
 ```
 
-Check out the branch if not already on it.
+Check out the branch if not already on it, **then require a clean working tree**
+(`git status --porcelain` empty) before touching anything:
+
+```bash
+[ -z "$(git status --porcelain)" ] || { echo "working tree not clean, refusing to start: would risk committing unrelated changes"; exit 1; }
+```
+
+This is the precondition step E's scoped `git add <file>` depends on: staging only the files a fix
+touched is safe *because* the tree started clean. Skip it and a file with pre-existing local edits
+gets those edits swept into the fix commit right along with it.
 
 ### 2. Loop (max 5 iterations)
 
-#### A. Push and wait
+Keep an explicit iteration counter and stop at 5: the cap is a real bound to enforce, not a figure
+of speech. Each pass through A–F is one iteration; on hitting the cap, go straight to the report.
+
+#### A. Wait for a review of the current head
+
+On **iteration 1**, if there is nothing to push yet (you haven't fixed anything in this loop), don't
+wait for a brand-new review: use whatever CodeRabbit has already posted as your starting point and
+go straight to step B. Otherwise:
 
 ```bash
+SINCE=$(date -u +%Y-%m-%dT%H:%M:%SZ)
 git push
 ```
 
@@ -62,11 +79,27 @@ If this repo doesn't auto-review on push, nudge it:
 gh pr comment <PR_NUMBER> --body "@coderabbitai review"
 ```
 
-Poll (every ~10s, timeout ~5min) for CodeRabbit's next formal review to land: a new entry in `gh api repos/{owner}/{repo}/pulls/<PR_NUMBER>/reviews` from `coderabbitai[bot]` created after this push. If you instead see a rate-limit comment ("review limit"), **stop the loop now** and go to Report with `blocked: rate-limited`.
+Poll (every ~10s, timeout ~5min) for CodeRabbit's next formal review to land: a new entry in
+`gh api --paginate repos/{owner}/{repo}/pulls/<PR_NUMBER>/reviews` from `coderabbitai[bot]`
+(REST spelling carries the `[bot]` suffix) created after `$SINCE`. Follow pagination so a review
+that lands on page two is not missed. If you instead see a rate-limit comment ("review limit"),
+**stop the loop now** and go to Report with `blocked: rate-limited`. If no review arrives within
+the timeout after one retry, stop and report the timeout honestly; do not claim success.
 
 #### B. Fetch unresolved findings
 
-Run the `unresolvedQodoThreads`-shaped query in `references/graphql-queries.md` (filter `author.login == "coderabbitai[bot]"` instead of Qodo's login). For each unresolved thread, parse the finding text and the **Prompt for AI Agents** block (heading text is `🤖 Prompt for AI Agents`, not `Agent Prompt`: match case/emoji-insensitively).
+Run the `unresolvedQodoThreads`-shaped query in `references/graphql-queries.md` (filter `author.login`
+on GraphQL's bare `coderabbitai`, **not** REST's `coderabbitai[bot]`: see the reference's login-spelling
+note, and follow `pageInfo.hasNextPage`/`endCursor` until exhausted). For each unresolved thread,
+parse the finding text, its `databaseId`, and the **Prompt for AI Agents** block (heading text is
+`🤖 Prompt for AI Agents`, not `Agent Prompt`: match case/emoji-insensitively).
+
+Mark each thread as seen with an 👀 reaction on its first comment (`databaseId` from the query), so
+the bot and a watching human can tell it is being worked:
+
+```bash
+gh api --method POST repos/{owner}/{repo}/pulls/comments/<DATABASE_ID>/reactions -f content=eyes
+```
 
 #### C. Check exit conditions
 
@@ -74,26 +107,68 @@ Stop if there are zero unresolved CodeRabbit threads, or max iterations reached.
 
 #### D. Fix each finding
 
-For each thread, in order: read the Prompt for AI Agents block in full: it names the issue and the fix. Apply it, staying inside its stated scope. If the suggestion is wrong, unsafe, or needs a product decision, don't force it: note that in step E instead.
+For each thread, in order: read the Prompt for AI Agents block in full: it names the issue and the fix. Apply it, staying inside its stated scope. If the suggestion is wrong, unsafe, or needs a product decision, don't force it: note that in step F instead. Track two lists as you go: **fixed** (thread id + the exact files you touched) and **skipped** (thread id + why). Do not resolve anything yet.
+
+#### E. Commit and push FIRST, before resolving anything
 
-#### E. Answer and resolve
+Order matters. A resolved thread is a claim that the fix is on the branch, so the push has to succeed
+before the claim is made: otherwise a failed commit or push leaves the PR unfixed with the finding
+marked resolved, and nobody looks at it again.
 
-**Reply to the thread first, then resolve it**, the "answer to the comments" half of the job:
+If step D changed code:
 
 ```bash
-gh api graphql -f query='mutation { addPullRequestReviewThreadReply(input: {pullRequestReviewThreadId: "<THREAD_ID>", body: "<REPLY>"}) { comment { id } } }'
+# Stage ONLY the files your fixes touched: never `git add -A`, which sweeps up
+# unrelated work and untracked secrets sitting in the worktree.
+git status --short                     # look before you stage
+git add <path> [<path>...]             # the files named in the findings you fixed
+git commit -m "address CodeRabbit review feedback (coderabbitloop iteration N)"
+git push
 ```
 
-Reply body: one or two sentences, what you changed and why, or exactly why you didn't fix it. Then resolve (`resolveReviewThread`). A finding you deliberately skip still gets a reply and gets resolved.
+Confirm the push actually landed before continuing:
 
-#### F. Commit and push
+```bash
+git rev-parse HEAD
+gh pr view <PR_NUMBER> --json headRefOid -q .headRefOid   # must match
+```
+
+If they differ, stop: the fix is not on the PR, so nothing may be resolved yet.
+
+#### F. Reply to each finding, react, then resolve
+
+Only now, with the fixes pushed, reply and resolve. **Reply to the thread first, then react, then
+resolve it**, the "answer to the comments" half of the job:
 
 ```bash
-git add -A
-git commit -m "address CodeRabbit review feedback (coderabbitloop iteration N)"
-git push
+gh api graphql -f query='
+  mutation($threadId: ID!, $body: String!) {
+    addPullRequestReviewThreadReply(input: {pullRequestReviewThreadId: $threadId, body: $body}) {
+      comment { id }
+    }
+  }' -f threadId="$THREAD_ID" -f body="$REPLY_TEXT"
 ```
 
+Pass the thread id and reply text as GraphQL **variables** (`-f threadId=... -f body=...`), never
+interpolated into the query string: a reply containing a quote, backtick, or newline breaks (or
+injects into) a hand-built query.
+
+Reply body: one or two sentences, what you changed and why, or exactly why you didn't fix it. A
+finding you deliberately skip still gets a reply and gets resolved.
+
+Then record the disposition as a reaction on the thread's first comment: the learning signal, and a
+visible marker for a human scanning the PR. 👍 (`+1`) for fixed, 👎 (`-1`) for skipped/rebutted.
+CodeRabbit reads a 👎 as feedback that the finding was wrong.
+
+```bash
+gh api --method POST repos/{owner}/{repo}/pulls/comments/<DATABASE_ID>/reactions -f content=+1
+# skipped/rebutted finding:
+gh api --method POST repos/{owner}/{repo}/pulls/comments/<DATABASE_ID>/reactions -f content=-1
+```
+
+Then resolve (`resolveReviewThread`). Reply first, react, then resolve: a reaction never replaces
+the reply, and a resolved thread with no reply loses the reasoning.
+
 Go back to step A.
 
 ### 3. Report
@@ -104,7 +179,7 @@ Go back to step A.
 | Findings resolved  | N     |
 | Findings skipped   | N (with reasons) |
 | Remaining          | N (if any) |
-| Blocked            | rate-limited / max-iterations / none |
+| Blocked            | rate-limited / timeout / max-iterations / none |
 
 ```
 Coderabbitloop complete.
@@ -115,4 +190,4 @@ Coderabbitloop complete.
 
 ## References
 
-- `references/graphql-queries.md`: shared with `qodoloop`: the exact `reviewThreads` query and the `resolveReviewThread` / `addPullRequestReviewThreadReply` mutations. Swap the author-login filter to `coderabbitai[bot]` and the prompt-heading match to `Prompt for AI Agents`.
+- `references/graphql-queries.md`: shared with `qodoloop`: the exact `reviewThreads` query (including the `databaseId` the reaction step needs) and the `resolveReviewThread` / `addPullRequestReviewThreadReply` mutations. Filter `author.login` on GraphQL's bare `coderabbitai` (never `coderabbitai[bot]`) and match the prompt heading `Prompt for AI Agents`.

package/adapters/cursor/olko-github-pr/skills/coderabbitloop/references/graphql-queries.md

@@ -6,6 +6,15 @@ against CodeRabbit's own documentation (`docs.coderabbit.ai/reference/review-com
 plus a real `<!-- ... summarize by coderabbit.ai -->` comment observed live:
 not guessed.
 
+**The bot's login string is spelled differently in REST vs GraphQL.** REST
+(`.user.login` on `pulls/.../comments`) returns `coderabbitai[bot]`. GraphQL
+(`author.login` on `reviewThreads`) returns `coderabbitai`, no `[bot]` suffix
+(confirmed live against PR #114's own threads). Using the REST spelling in a
+GraphQL filter silently matches nothing, which reads as "no findings" instead
+of "wrong filter": exactly the kind of bug that has no crash and no error to
+notice. Use `[bot]` only in REST-based jq filters (`.user.login`); use the
+bare name everywhere you're filtering a GraphQL `author.login`.
+
 ## Fetch unresolved CodeRabbit threads (paginated)
 
 ```graphql
@@ -18,7 +27,7 @@ query($cursor: String) {
           id
           isResolved
           comments(first: 1) {
-            nodes { body path line author { login } }
+            nodes { databaseId body path line author { login } }
           }
         }
       }
@@ -27,12 +36,13 @@ query($cursor: String) {
 }
 ```
 
-Filter client-side to `coderabbitai[bot]` and `isResolved == false`:
+Filter client-side to GraphQL's `coderabbitai` (bare name, see the note above)
+and `isResolved == false`:
 
 ```bash
 gh api graphql -f query='...' --jq \
   '.data.repository.pullRequest.reviewThreads.nodes[]
-   | select(.comments.nodes[0].author.login == "coderabbitai[bot]")
+   | select(.comments.nodes[0].author.login == "coderabbitai")
    | select(.isResolved == false)'
 ```
 
@@ -53,14 +63,18 @@ description text above it: not every low-confidence nit gets one.
 
 ```bash
 gh api graphql -f query='
-mutation {
-  addPullRequestReviewThreadReply(input: {
-    pullRequestReviewThreadId: "THREAD_ID"
-    body: "REPLY_TEXT"
-  }) { comment { id } }
-}'
+  mutation($threadId: ID!, $body: String!) {
+    addPullRequestReviewThreadReply(input: {pullRequestReviewThreadId: $threadId, body: $body}) {
+      comment { id }
+    }
+  }' -f threadId="$THREAD_ID" -f body="$REPLY_TEXT"
 ```
 
+Pass the thread id and reply text as GraphQL **variables** (`-f`), never interpolated straight into
+the query string. A reply containing a quote, backtick, or embedded newline breaks (or, worse,
+injects into) a hand-built query string; `gh api graphql -f` handles the escaping correctly when the
+value travels as a variable instead.
+
 `pullRequestReviewThreadId` and `body` are the only required fields.
 
 ## Resolve a thread (batch)
@@ -81,6 +95,24 @@ marks every one of its threads resolved at once server-side. That's a valid
 bulk escape hatch if the user wants to blow through remaining low-value nits,
 but it skips the per-finding reply: don't use it as the default path.
 
+## React to a comment (the bot's learning signal)
+
+Reacting needs the comment's REST id, which is why `databaseId` is selected in
+the thread query above. The reaction set is fixed; only eight values exist:
+`+1`, `-1`, `laugh`, `confused`, `heart`, `hooray`, `rocket`, `eyes`.
+
+```bash
+# 👀 as soon as you start working a finding
+gh api --method POST repos/{owner}/{repo}/pulls/comments/<DATABASE_ID>/reactions -f content=eyes
+# 👍 when it was accepted and fixed, 👎 when it was rebutted (the correction signal)
+gh api --method POST repos/{owner}/{repo}/pulls/comments/<DATABASE_ID>/reactions -f content=+1
+gh api --method POST repos/{owner}/{repo}/pulls/comments/<DATABASE_ID>/reactions -f content=-1
+```
+
+React after the reply and before the resolve, so GitHub records the reason and
+the disposition together. A reaction never replaces the reply. CodeRabbit reads
+a 👎 on one of its comments as feedback that the finding was wrong.
+
 ## Fetch the walkthrough/summary comment (context only, not the source of truth)
 
 ```bash