# Gh Address Comments

> Help address review/issue comments on the open GitHub PR for the current branch using gh CLI; verify gh auth first and prompt the user to authenticate if not logged in.

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

---


# PR Comment Handler

Guide to find the open PR for the current branch and address its comments with gh CLI. Run all `gh` commands with elevated network access.

Prereq: ensure `gh` is authenticated (for example, run `gh auth login` once), then run `gh auth status` with escalated permissions (include workflow/repo scopes) so `gh` commands succeed. If sandboxing blocks `gh auth status`, rerun it with `sandbox_permissions=require_escalated`.

## 1) Inspect comments needing attention
- Run `python3 ./scripts/fetch_comments.py` which will print out all the comments and review threads on the PR

## 2) Ask the user for clarification
- Number all the review threads and comments and provide a short summary of what would be required to apply a fix for it
- Ask the user which numbered comments should be addressed

## 3) If user chooses comments
- Address each selected comment **one at a time**, in order
- For each comment:
  1. Apply the code fix
  2. **Build & verify** before committing:
     - Detect the project type and run the appropriate build/test commands:
       - **iOS/Swift/Xcode:** Prefer **Xcode MCP** first, then **XcodeBuildMCP**, and fall back to `xcodebuild` CLI only if neither MCP is available. Build the relevant scheme/target, then run tests.
       - **Node/JS/TS:** `npm run build` / `yarn build`, then `npm test` / `yarn test`
       - **Make-based:** `make`, then `make test`
       - Or whatever build/test setup the project uses
     - At minimum, run tests covering the changed files
     - If the build or tests fail, fix the issue before proceeding — do not commit broken code
  3. Stage only the affected files with `git add <files>`
  4. Commit with a message that:
     - Summarizes the change on the first line (e.g. `Fix null check in parseConfig as requested in review`)
     - Includes a blank line, then a short explanation of **what the reviewer asked for** and **what was changed to address it**
  5. Push the commit and reply on the PR review thread with a short summary of the fix and the commit hash (e.g. `"Added a nil check before accessing the property. (a1b2c3d)"`)
  6. Move on to the next comment
- For comments the user chose **not** to address, reply on the PR thread explaining why (e.g. over-engineering, not applicable, etc.) so the reviewer knows their feedback was considered
- After all comments are handled, show a summary of all commits made

## 4) Post-run summary
- List each commit (hash + message) created during this session
- Ask the user if they want to push the branch

Notes:
- If gh hits auth/rate issues mid-run, prompt the user to re-authenticate with `gh auth login`, then retry.