From review
Fetches, triages, validates, and addresses gemini-code-assist bot PR comments on GitHub: skeptical analysis of suggestions, user-approved fixes only after summary table.
npx claudepluginhub himattm/skills --plugin reviewThis skill uses the workspace's default tool permissions.
Fetch, validate, triage, and address `gemini-code-assist[bot]` PR review comments. Core principle: **skeptical triage, not blind compliance.** Gemini lacks cross-file context and project history — treat its suggestions as hints, not instructions.
Mandates invoking relevant skills via tools before any response in coding sessions. Covers access, priorities, and adaptations for Claude Code, Copilot CLI, Gemini CLI.
Share bugs, ideas, or general feedback.
Fetch, validate, triage, and address gemini-code-assist[bot] PR review comments. Core principle: skeptical triage, not blind compliance. Gemini lacks cross-file context and project history — treat its suggestions as hints, not instructions.
Read references/github-api-patterns.md for exact gh api commands, field names, and reply formats.
Use $ARGUMENTS if provided (e.g., /address-gemini-review 82). Otherwise auto-detect:
gh pr view --json number --jq '.number'
Fail clearly if no PR is found.
Run both calls from the reference file (inline comments + formal reviews). Filter to gemini-code-assist[bot]. Skip comments where in_reply_to_id is set (those are replies, not original comments).
If zero comments found, say so and stop. No further action needed.
For each comment, extract: id, path, line, start_line, body, severity badge, and any suggestion block. Group by file path.
For each comment, read the actual file at the referenced lines. Then evaluate:
| Question | If No |
|---|---|
| Is the comment technically correct about the current code? | DISMISS |
| Is the suggestion syntactically and semantically correct? | DISMISS the suggestion (may still FIX differently) |
| Is this worth the churn? (severity vs effort vs risk) | DISMISS |
| Does it conflict with existing architecture or project conventions? | DISMISS |
| Does it require human judgment (trade-off, product decision)? | DISCUSS |
Apply receiving-code-review skepticism:
Assign each comment: FIX / DISMISS / DISCUSS
Present a table:
| # | File | Line | Severity | Verdict | Reason |
|---|------|------|----------|---------|--------|
| 1 | src/foo.ts | 42 | medium | FIX | Redundant sort — suggestion is correct |
| 2 | src/bar.ts | 18 | low | DISMISS | Already handled by upstream validator |
Then for each comment, show the Gemini comment body (truncated), your analysis, and verdict rationale.
ASK THE USER: "These are my proposed verdicts. Approve, or tell me which to change."
DO NOT implement anything until the user explicitly approves. This gate is non-negotiable.
For approved FIX items only:
Using the reply endpoint from the reference file, reply to every Gemini comment — including dismissed ones:
"Fixed in {sha}. {what changed}.""Not applicable — {technical reason}.""Flagged for discussion — {why}."No performative language. No "Great catch!" No "Thanks for the suggestion!" Just the technical substance.
Single commit for all fixes: fix: address gemini review on PR #{number}
If all comments were dismissed (no code changes), skip the commit — replies are sufficient.
| Mistake | Fix |
|---|---|
| Implementing before triage approval | The hard gate at step 5 exists for a reason — wait |
| Blindly applying suggestion blocks | Suggestions can be wrong. Validate against the actual code |
| Creating new top-level comments instead of thread replies | Use the /replies endpoint, not /comments |
| Hardcoding owner/repo | Always detect dynamically via gh repo view |
| Performative reply language | Direct and technical only |
| Skipping replies for dismissed comments | Every comment gets a reply — paper trail matters |
| Treating all Gemini comments equally | Severity + your own judgment determine priority |