address-pr-commentslisted

Triages every open review thread on a merge/pull request, then does something about each one: implements a tested fix, replies in-thread with the fixing commit, and resolves it — or, for a thread you disagree with, replies with your reasoning and leaves it open for the human reviewer to close. Ships with adapters for GitLab and GitHub as the code host, but degrades gracefully to any other host reachable via tool discovery. User-only: runs only when explicitly invoked with /address-pr-comments <MR or PR URL>. When the user wants to work through reviewer feedback on a GitLab MR or GitHub PR, resolve review comments, or address a round of code review, suggest running this command rather than triaging threads by hand.
azborgonovo/ai-skills · ★ 0 · Code & Development · score 78

Install: claude install-skill azborgonovo/ai-skills

# Address PR/MR Comments Works through every open review thread on a merge or pull request: fixes what needs fixing, then replies and resolves. Throughout this skill "change" is the generic term for what the host calls a merge request (GitLab) or pull request (GitHub) — the host adapter keeps that host's own word when naming the concrete API object or CLI call. "Thread" is the generic term for a GitLab discussion or a GitHub review thread: a root comment plus its replies, resolvable independently of the rest of the change. The workflow is host-agnostic; the host-specific mechanics live in adapter files under `references/` and load only when you reach the step that needs them. This keeps the always-loaded body focused on judgment — classifying each thread and fixing the code, which is the same regardless of where the change lives. This isn't a code review — it only acts on threads reviewers have already raised, and doesn't evaluate the change on its own merits. For a first-pass review that surfaces new findings, use `/pr-review` instead. ## Workflow Work through steps in order. ### Step 1 — Identify the host and load its adapter Determine which host the change lives on, primarily from the URL shape: - `…/-/merge_requests/<n>` → GitLab → read `references/hosts/gitlab.md` - `github.com/<owner>/<repo>/pull/<n>` → GitHub → read `references/hosts/github.md` The adapter file is the authority for that host's mechanics: URL parsing, auth check, the exact calls to list thread