# Gh Address Comments

> Help address review comments on the open GitHub PR for the current branch using gh CLI. Verify gh authentication, fetch unresolved review threads, summarize the actionable items, and implement selected fixes after the user chooses which comments to address.

- Skill: `jlnbuiles/gh-address-comments` (Agent Skill, multi-file: 6 files)
- Install (CLI): `npx skillmds@latest add jlnbuiles/gh-address-comments`
- Raw SKILL.md: https://api.skillmd.com/api/skills/jlnbuiles/gh-address-comments/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Research & Search
- Author: jlnbuiles (https://skillmd.com/u/jlnbuiles)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/jlnbuiles/gh-address-comments

---


# GitHub Address Comments

Use this skill when the user wants to work through GitHub PR review comments.

Run all `gh` commands with elevated network access.

## Expert Standard

- Think like an experienced reviewer and maintainer, not a comment clerk.
- Give advice like an expert: separate true defects from preference, explain which comments matter, and do not over-fix.
- Execute like an expert: preserve intent, make focused changes, and keep the PR moving.

## Communication Style

- Summaries should use simple words and short sentences.
- Translate each review thread into one plain-English action or response.
- Avoid GitHub or architecture jargon when a simpler phrase works.
- Make it obvious what needs code, what needs tests, and what only needs a reply.

## Inputs

- `repo`: repo path, default `.`
- `pr`: PR number or URL, optional; default current branch PR

## Workflow

1. Run `gh auth status`. If auth fails, stop and ask the user to run `gh auth login`.
2. Fetch comments with:
   `python "<path-to-skill>/scripts/fetch_comments.py" --repo "." --summary --unresolved-only`
3. Triage each item as:
   - code change
   - test gap
   - docs / explanation
   - disagreement / pushback
4. Present a short numbered list with reviewer, location, summary, and likely response.
5. Ask which items to address.
6. Implement only the selected items.
7. Summarize what changed, what remains unresolved, and what checks were run.

## Rules

- Prefer unresolved threads first.
- Do not force code changes when an explanation is enough.
- If a reviewer request is incorrect or conflicts with the codebase direction, explain that before changing code.
- Preserve unrelated local changes.
- Keep triage expert-level, but phrase the user-facing summary so it is easy to understand quickly.