fu-jie/pr-reviewer

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