v1.1 to v1.2

---

name: geminiloop

description: >

Iteratively satisfy Gemini Code Assist's review on a GitHub PR, but treat every Gemini comment

SKEPTICALLY (Gemini Code Assist is materially more error-prone than Greptile): verify each finding

against the real code first, fix ONLY the genuinely-correct ones, and rebut + resolve false

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 + jq + gh (GitHub CLI) authenticated, and the Gemini Code Assist app installed on the repo.

metadata:

allowed-tools: Bash(gh:*) Bash(git:*)

---

# Geminiloop

Drive a GitHub PR until Gemini Code Assist has no unresolved comments, **but do not cargo-cult

its suggestions.** Gemini is often confidently wrong. Every comment is a *claim to verify*, not an

instruction to obey. A wrong suggestion applied is worse than the comment itself.

## How Gemini differs from other review bots

- **No check-run, no score.** Gemini does not publish a `X/5` confidence or a `greptile` check. It

posts a **PR review** (state `COMMENTED`) authored by `gemini-code-assist[bot]` with a

`## Code Review` summary body plus inline review comments. Detection is by polling the *reviews*

- **Auto-reviews on push/open.** It reviews automatically when a PR opens or gets new commits;

`/gemini review` forces a fresh pass.

- **Severity, not confidence.** Inline comments carry a priority badge (a `![critical]` /

`![high]` / `![medium]` / `![low]` shields image) at the top of the body. Weight `critical`/`high`

seriously; treat `medium`/`low` as usually-skippable nits unless clearly correct.

- **Higher false-positive rate.** This is the whole point of the skill: bias toward *rebut* over

*change*.

## Not for

- GitLab / Perforce (Gemini Code Assist is GitHub-only). For other review bots this catalog ships

`copilotloop`, `codexloop`, `coderabbitloop`, and `qodoloop`; for CI failures rather than review comments, use

`ci-fix-loop`.

## 1. Identify the PR

```bash

gh pr view --json number,headRefName,headRefOid -q '{number,branch:.headRefName,head:.headRefOid}'

```

Switch to the PR branch if not already on it. Capture `OWNER`/`REPO` (`gh repo view --json owner,name`).

## 2. The loop (max 5 iterations)

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–G is one iteration; on hitting the cap, go straight to the

report and list what is still unresolved rather than starting a sixth.

```bash

```

### B. Fetch the findings

overall take and the severity spread.

```bash

```

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

anything.** Read the file, the surrounding code, the types, and any call sites. Then classify:

1. **CORRECT + actionable**: the finding is real and the fix improves the code. → fix it (step D).

2. **FALSE POSITIVE / technically wrong**: the claim doesn't hold. → do **NOT** change code; write a

specific, evidence-based reply (cite the exact code/line/behavior that disproves it), then resolve.

3. **Valid but out-of-scope / stylistic nit** that conflicts with repo convention or the PR's intent

→ briefly decline with a reason, then resolve. Do not expand the PR's scope to satisfy a nit.

**Hard rules:**

- **Never modify correct code just to silence Gemini.** Prefer a reasoned rebuttal.

- When uncertain whether a claim holds, **investigate** (read more code, run the type-checker / tests)

rather than assume Gemini is right. Default to skepticism.

- If a suggested change would break other call sites, alter public behavior, or contradict a verified

repo convention, it is a category-2 rebuttal, not a fix.

- Never fabricate identifiers to satisfy a comment (e.g. a Linear/ticket prefix). If Gemini asks for a

ticket reference and none exists, say so; do not invent one.

**Gemini's common failure modes to watch for (default these to category 2):**

- Hallucinated APIs, options, or framework behavior stated as fact.

- "Add a null/undefined check" where the type already guarantees presence.

- Suggestions that compile-break or break other callers.

- Security/perf warnings with no actual exploit path or measurable cost.

- Restating library/framework semantics incorrectly.

- Style demands that contradict the repo's existing, consistent pattern.

### D. Apply fixes: category 1 only

Make the minimal correct change. Re-run the local gate if the repo has one (typecheck/tests) before

moving on.

### E. Commit and push FIRST, before resolving anything

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.

If step D changed code:

```bash

# 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 gemini review feedback (geminiloop iteration N)"

git push

```

Author the commit per the repo's norms (e.g. the user's identity; no AI attribution if that is the

convention). Confirm the push actually landed before continuing:

```bash

git rev-parse HEAD

gh pr view <PR> --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 and resolve every addressed thread

Reply on a thread's comment via `gh api repos/{owner}/{repo}/pulls/<PR>/comments -f body="..." -F in_reply_to=<comment_id>`,

then resolve:

```bash

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.

Threads you are **rebutting** need no push, so they may be replied to and resolved regardless of

whether step D changed code.

## 3. Exit conditions

Stop when **any** is true:

## 4. Report

```text

Geminiloop complete.

PR: #<n>

Iterations: N

Comments fixed: N (genuinely-correct findings)

Comments rebutted: N (false positives / nits, resolved with rationale)

```

If it stopped at max iterations, list the remaining threads with your current assessment

(fix-pending vs disputed) so a human can arbitrate.