consider-pr-feedback

Files (2)

• README.md
• SKILL.md

SKILL.md (first lines)

# Consider PR feedback

Walks one open pull request and answers two questions for the user:

1. Is CI green? If not, **what** failed and **why** — then offer to fix.
2. What feedback did reviewers leave that hasn't been addressed yet?
   Summarize each item, then **ask** which (if any) to implement. Do not
   start editing files until the user picks.

Argument: optionally a PR number or URL (`/consider-pr-feedback 42`). If
omitted, use the PR for the current branch.

Requires `gh` (GitHub CLI) authenticated for the repo or Github MCP.

Gather all information from CI and reviewer feedback before proposing fixes to the user.

## Step 1 — resolve the PR

If an argument was provided, use it. Otherwise resolve from the current
branch:

```bash
gh pr view --json number,url,headRefName,state,title,headRefOid
```

If there is no open PR for the branch, stop and tell the user — offer to
push + open one if they want.

Capture `number` and the `owner/repo` (from the URL) — every other call
needs them.

## Step 2 — check CI

Get a fast human view first:

```bash
gh pr checks            # exits non-zero if any required check is failing
```

For structured handling, use JSON. The valid fields are limited — the
`bucket` field is what you want (`pass` / `fail` / `pending` /
`skipping` / `cancel`); there is no `conclusion` field:

```bash
gh pr checks --json name,state,bucket,link
```

If all `bucket == "pass"`: state "CI is green" and continue to Step 3.

If any are `pending`: tell the user CI is still running, list which
checks, and stop. Don't proceed to "fix" something that may yet pass.

If any are `fail`: for each failure, derive the run ID from the `link`
(`.../actions/runs/<RUN_ID>/job/<JOB_ID>`) and pull failure logs:

```bash
gh run view <RUN_ID> --log-failed | tail -200
```

Read the failing-step output, identify the root cause, and **propose a
specific fix** — name the file, the change, and why. Then ask the user
if you should apply it. Fix CI before turning to reviewer feedback —
addressing comments on top of a broken build wastes a push.

## Step 3 — fetch reviewer feedback

There are **three** distinct feedback surfaces on a PR. Pull all three;
each holds things the others don't.

```bash
# (a) Formal reviews (approve / request-changes / comment + body)
gh pr view --json reviews

# (b) Inline review comments (threaded on specific diff lines)
gh api "repos/<OWNER>/<REPO>/pulls/<NUMBER>/comments" \
  --jq '.[] | {id, path, line, commit_id, user: .user.login, body}'

# (c) Top-level PR conversation (the "Conversation" tab discussion)
gh api "repos/<OWNER>/<REPO>/issues/<NUMBER>/comments" \
  --jq '.[] | {id, user: .user.login, body}'
```

### Filter what's still actionable

- **APPROVED reviews with no body** — skip; nothing to address.
- **Outdated inline comments** — if a comment's `commit_id` is not in
  the current PR head's history, the line has likely moved or been
  rewritten. Note it as "stale, verify manually" rather than treating
  it as live. Compare against the PR's current `headRefOid` from Step
  1, or `git log --oneline <commit_id>..HEAD` to see if it's an
  ancestor.
- **Same author multiple times** — keep all; later ones may supersede
  earlier ones, but the user is the judge.
- **Bot vs human** — don't filter by author. Bot review comments are
  often substantive and shouldn't be hidden.
- **Pending reviews are invisible** — a reviewer's comments do not
  appear on any of the three surfaces until they submit the review. If
  the user insists a comment exists and you can't see it, say so and
  ask them to submit the pending review.

## Step 4 — present and ask

Print a compact summary the user can scan:

```
PR #12 — Migrate web app to the new router
CI: ✓ all 5 checks passing

Reviewer feedback (2 items):

  [1] review from alice (COMMENTED) — 2026-05-27
      "Blocking: the same-origin backend migration is missing matching
       production proxy routes. The web client now calls /projects and
       /assets but the deployment doc only forwards /api/*."

  [2] inline comment on docs/deployment.md:29 from review-bot
      "This proxy rule no longer matches the web app's backend calls..."
```

From erikreppel/skills, MIT.

More from erikreppel/skills