Extract and analyze writing improvements from GitHub PR review comments. Use when asked to show review feedback, style changes, or editorial improvements from a GitHub pull request URL. Handles both explicit suggestions and plain text feedback. Produces structured output comparing original phrasing with reviewer suggestions to help refine future writing.
Analyze and address unresolved feedback on a GitHub pull request. Use when the user has received PR review comments and wants to systematically address each piece of feedback, or when the user mentions PR feedback, review comments, or addressing reviewer concerns.
This skill should be used when a user asks for a code review, feedback on a PR or MR, diff assessment, or says things like 'can you review my changes', 'look at this diff', 'is this ready to merge', 'check my code', 'review this branch', 'what do you think of these changes', or 'LGTM check'. Covers correctness, tests, performance, security, and architecture feedback on pull/merge requests or raw diffs from any platform (GitHub, GitLab).
Use when the user has received review comments on a GitHub PR or GitLab MR and needs to process them — analyze, triage, coordinate fixes, respond, and resolve threads. This is THE skill for any post-review work on a PR/MR. Triggers on: "разберись с комментариями", "address review comments", "handle review feedback", "respond to reviewers", "fix review comments", "deal with PR/MR comments", "reply to review", "resolve review threads", "go through the feedback", "комментарии к PR/MR", "ревьюер оставил комментарии", "пройдись по комментариям", "тредов после ревью", "reviewer left comments", "got a review", "review feedback on my MR/PR", or any mention of processing, triaging, or responding to existing review comments on a pull request or merge request. Do NOT use for writing new reviews, creating PRs, or CI/CD monitoring — those are separate skills. --- # Address Review Feedback An orchestrator skill. Analyzes all review comments, categorizes them, detects cross-diff patterns, presents an action plan for user confirmation, then coordinates fixes, answers, and thread responses. Does NOT implement code changes itself — it produces task descriptions for implementation agents. **Core principle:** Fix what belongs to this PR. Push back when a suggestion is wrong. Never perform agreement — just act and show evidence. --- ## Phase 1: Fetch & Parse ### Platform detection ```bash REMOTE_URL=$(git remote get-url origin) # Contains github.com → GitHub (gh) # Contains gitlab → GitLab (glab) ``` ### Fetch PR/MR metadata and context Fetch both technical metadata and the PR/MR context — description, linked issues, labels, milestone. This context is essential for Phase 2: understanding the intent behind changes lets you judge whether a comment is in scope, whether a suggestion aligns with the goal, and what trade-offs matter. ```bash # GitHub — metadata + context in one call PR_INFO=$(gh pr view --json number,baseRefName,headRefName,title,body,labels,milestone,closingIssuesReferen