Fu-Jie_openwebui-extensions/.gemini/skills/pr-reviewer/SKILL.md

name, description

name	description
pr-reviewer	Fetches PR review comments, analyzes requested changes, implements fixes, commits and pushes the resolution. Use after a reviewer has left comments on an open PR to close the feedback loop efficiently.

PR Reviewer

Overview

This skill automates the response cycle for code review. When a reviewer leaves comments on a Pull Request, this skill fetches all pending feedback, categorizes issues by severity, implements fixes, and submits a follow-up commit with appropriate review response comments.

Prerequisites

• An open PR exists with pending review comments
• The local branch matches the PR's head branch
• gh CLI is authenticated

---

Workflow

Step 1 — Fetch Review State

Retrieve all review comments and overall review status:

# Get overall review decisions
PAGER=cat GH_PAGER=cat gh pr view <PR-NUMBER> --json reviews,reviewDecision,headRefName \
  --jq '{decision: .reviewDecision, reviews: [.reviews[] | {author: .author.login, state: .state, body: .body}]}'

# Get inline code comments (specific line comments)
PAGER=cat GH_PAGER=cat gh api repos/Fu-Jie/openwebui-extensions/pulls/<PR-NUMBER>/comments \
  --jq '[.[] | {path: .path, line: .line, body: .body, author: .user.login, id: .id}]'

# Get general issue comments
PAGER=cat GH_PAGER=cat gh issue view <PR-NUMBER> --comments --json comments \
  --jq '[.comments[] | {author: .author.login, body: .body}]'

Confirm the current local branch matches the PR head:

git branch --show-current

If mismatched, checkout the correct branch first.

Step 2 — Categorize Review Feedback

Group feedback into categories:

Category	Examples	Action
Code Bug	Logic error, incorrect variable, broken condition	Fix code immediately
Style / Formatting	Indentation, naming convention, missing blank line	Fix code
Documentation	Missing i18n key, wrong version in README, typo	Fix docs
Design Question	Suggestion to restructure, alternative approach	Discuss with user before implementing
Nitpick / Optional	Minor style preferences reviewer marked as optional	Fix if quick; document if skipped
Blocking	Reviewer explicitly blocks merge	Must fix before proceeding

Present the full categorized list to the user and confirm the resolution plan.

Step 3 — Implement Fixes

For each accepted fix:

1. Read the affected file at the commented line for context:

   sed -n '<line-5>,<line+10>p' <file-path>
   

2. Apply the fix using appropriate file edit tools
3. After editing, verify the specific area looks correct

For code changes that might affect behavior:

• Check if tests exist: ls tests/test_*.py
• If tests exist, run them: python -m pytest tests/ -v

For documentation fixes:

• If modifying README.md, check if docs/ mirror needs the same fix
• Apply the same fix to both locations

Step 4 — Run Consistency Checks

After all fixes are applied:

# Version consistency (if any version files were touched)
python3 scripts/check_version_consistency.py

# Quick syntax check for Python files
python3 -m py_compile plugins/{type}/{name}/{name}.py && echo "✅ Syntax OK"

Step 5 — Stage and Commit

Create a new commit (do NOT amend if the branch has already been pushed, to avoid force-push):

git add -A
git status

Draft a Conventional Commits message for the fixup:

Format: fix(scope): address review feedback

Body should list what was fixed, referencing reviewer concerns:

fix(github-copilot-sdk): address review feedback from @reviewer

- Fix X per review comment on line Y of file Z
- Update README to clarify auth requirement
- Correct edge case in _parse_mcp_servers logic

git commit -m "<fixup commit message>"

Step 6 — Push the Fix Commit

git push origin $(git branch --show-current)

Force-push policy:

• Use git push (non-force) by default
• Only use git push --force-with-lease if:
  1. The user explicitly requests it, AND
  2. The only change is an amended commit squash (cosmetic, no logic change)
  3. Never use --force (without --lease)

Step 7 — Respond to Reviewers

For each addressed review comment, post a reply:

# Reply to inline comment
gh api repos/Fu-Jie/openwebui-extensions/pulls/<PR-NUMBER>/comments/<COMMENT-ID>/replies \
  -X POST -f body="Fixed in commit <SHORT-SHA>. <Brief explanation of what was changed.>"

# General comment to summarize all fixes
gh issue comment <PR-NUMBER> --body "All review feedback addressed in commit <SHORT-SHA>:
- Fixed: <item 1>
- Fixed: <item 2>
Ready for re-review. 🙏"

Step 8 — Re-Request Review (Optional)

If the reviewer had submitted a CHANGES_REQUESTED review, request a new review after fixes:

PAGER=cat GH_PAGER=cat gh api repos/Fu-Jie/openwebui-extensions/pulls/<PR-NUMBER>/requested_reviewers \
  -X POST -f reviewers[]='<reviewer-login>'

---

Decision Guide

When NOT to implement a suggestion immediately

• Design questions: "Should this be a separate class?" — Present to user for decision
• Optional nitpicks: Reviewer marked as nit: — Ask user if they want to include it
• Large refactors: If fix would require changing >50 lines, propose a separate follow-up issue instead

When to ask the user before proceeding

• Any fix involving behavioral changes to plugin logic
• Renaming Valve keys (breaking change — requires migration notes)
• Changes that affect the bilingual release notes already committed

---

Anti-Patterns to Avoid

• ❌ Do NOT git commit --amend on a pushed commit without user approval for force-push
• ❌ Do NOT silently skip a reviewer's comment; always acknowledge it (implement or explain why not)
• ❌ Do NOT use --force (only --force-with-lease when absolutely necessary)
• ❌ Do NOT make unrelated changes in the fixup commit; keep scope focused on review feedback
• ❌ Do NOT respond to reviewer comments in Chinese if the PR language context is English