resolve-review-notes

Files (1)

• SKILL.md

SKILL.md (first lines)

# Resolve Review Notes

## Mission

Resolve review feedback on the GitHub pull request for the current branch end-to-end.

## Prerequisites

- Run inside a Git repository with a non-detached current branch.
- GitHub CLI (`gh`) must be installed and authenticated for the repository host.
- The current branch must have an open pull request unless the user explicitly identifies another PR.

## Feedback Scope

Collect all feedback, not only unresolved inline threads:
- inline pull request review threads, including replies, outdated comments, and resolution state
- submitted reviews and their top-level review bodies
- pull request conversation comments

Treat a thread and its replies as one feedback item. Ignore only empty review bodies and purely administrative events; record bot feedback and human feedback alike.

## Workflow

1. Discover the pull request.
- Verify authentication with `gh auth status`.
- Read the current branch with `git branch --show-current`; stop on a detached HEAD.
- Resolve the PR with `gh pr view --json number,url,title,state,headRefName,baseRefName,reviewDecision`.
- Confirm the returned `headRefName` matches the current branch. If no open PR exists, report that clearly and stop; do not guess another PR.

2. Collect the complete feedback inventory.
- Use `gh api --paginate` for REST collections and `gh api graphql` with cursor pagination for review threads.
- Fetch review threads with thread IDs, `isResolved`, `isOutdated`, file path, line/original line, and every comment's ID, author, body, URL, and timestamps.
- Fetch submitted reviews from `repos/{owner}/{repo}/pulls/{number}/reviews`.
- Fetch conversation comments from `repos/{owner}/{repo}/issues/{number}/comments`.
- Preserve comment URLs and IDs so every outcome is auditable.
- Deduplicate review bodies or replies already represented in a review thread. Build an inventory before making edits so pagination gaps cannot silently omit later comments.

3. Validate every feedback item against the checked-out branch.
- Read the current code and relevant tests at the referenced location; for outdated comments, locate the corresponding current code by symbol or nearby context.
- Determine the reviewer's concrete claim or requested change and test it against current behavior, repository conventions, and available checks.
- Classify each item as:
  - `valid`: the issue still exists and the requested outcome is appropriate
  - `already-addressed`: current code already satisfies the comment
  - `not-applicable`: the claim does not hold for the current code, with evidence
  - `ambiguous`: intent or desired behavior requires a human decision
- Record a concise rationale and evidence for every classification. Do not treat resolved or outdated status as proof that a comment is addressed.

4. Fix valid items.
- Apply minimal edits.
- Group related fixes.
- Re-run relevant checks (lint/test/build where available).

5. Update GitHub review threads.
- Re-fetch thread state before mutating it to account for comments added during the run.
- For fixed or already-addressed inline threads, post a concise evidence-based reply when useful, then resolve the thread with GitHub's `resolveReviewThread` GraphQL mutation.
- Leave `not-applicable` and `ambiguous` threads unresolved unless the user explicitly asks otherwise; report the rationale or blocker.
- Do not resolve a thread when checks for its fix are failing.
- Do not edit, delete, minimize, or dismiss reviewers' comments or reviews.

6. Produce summary.
- Write `reports/resolve-review-notes-summary.md` with:
  - PR number and URL
  - total processed
  - fixed
  - already addressed
  - not applicable
  - ambiguous/pending
  - comment URL and validation rationale for every item
  - files changed
  - checks executed and results
  - threads resolved and threads left open

## Guardrails

- Do not fabricate reviewer intent when ambiguous.
- Do not make speculative logic changes without evidence.
- Do not skip comments because they are old, resolved, generated by a bot, or attached to outdated code.
- Do not expose authentication tokens or private PR content outside the repository and GitHub host.
- Do not approve, dismiss, merge, close, or submit the pull request.
- Do not push changes unless explicitly requested.
- Prefer one coherent commit plan, but do not commit unless explicitly requested.

From veverkap/skills, MIT.

More from veverkap/skills