address-pr-comments

Files (1)

• SKILL.md

SKILL.md (first lines)

> **Tool mapping (OpenCode):** This skill uses:
> - `question` tool for user prompts (not `AskUserQuestion`)
> - `task` tool for subagents (not `Agent` or `Task` subagent syntax)
> - `skill({ name: "..." })` to load other skills (not `Skill(skill="...", args="...")`)
> - `codegraph_explore`, `codegraph_search`, `codegraph_context` for codebase exploration (preferred)
> - `todowrite` for phase/progress tracking
> - `grep`, `glob`, `read`, `bash` as fallback when `.codegraph/` not initialized
>
> **Context rule:** This skill supersedes any prior skill instructions. Follow ONLY these instructions now. Read the user's goal and any mode/include/skip from the conversation context.

> **User-question protocol:** Whenever this skill needs the user to pick between options, confirm an action, or answer a multiple-choice prompt, you MUST call the `question` tool to render a proper interactive picker. Do NOT print numbered options as plain text and wait for the user to type a number — that produces a degraded UX. Free-form questions (open-ended typing) may be asked in prose, but any time you would write "1) … 2) … 3) …", use `question` instead.


# Address PR Comments

Resolve every reviewer thread on a PR with a per-comment commit, a reply, and a resolved thread. Reviewer ends with zero unresolved threads and a clear audit trail.

---

## Phase 1 — Locate the PR

Use `todowrite` to mark this phase as in_progress.

Determine the target PR from the user's argument or current branch:

```bash
# explicit number/URL provided
gh pr view <number-or-url> --json number,headRefName,baseRefName,url,state,isDraft

# current branch
gh pr view --json number,headRefName,baseRefName,url,state,isDraft

# issue number provided — find linked PR
gh issue view <number> --json closedByPullRequestsReferences
```

**Exit conditions:**
- PR found and `state=OPEN` → continue.
- No PR for current branch → ask the user for a PR number/URL; do not guess.
- PR is `MERGED` or `CLOSED` → stop and ask the user to confirm.

Checkout the PR branch if not already on it: `gh pr checkout <number>`.

---

## Phase 2 — Fetch ALL comments

Use `todowrite` to mark this phase as in_progress.

Two distinct APIs. Run both — missing one means missing comments.

```bash
PR=<number>
REPO=$(gh repo view --json nameWithOwner -q .nameWithOwner)  # e.g. owner/repo
OWNER=${REPO%/*}
NAME=${REPO#*/}

# Inline (review) comments — anchored to a file/line
gh api "repos/$REPO/pulls/$PR/comments" --paginate \
  --jq '.[] | {id, user: .user.login, path, line, body, in_reply_to_id, commit_id, created_at, html_url}'

# PR-level issue comments (top-level conversation, not anchored)
gh api "repos/$REPO/issues/$PR/comments" --paginate \
  --jq '.[] | {id, user: .user.login, body, created_at, html_url}'

# Review threads with resolved state (GraphQL — needed to skip already-resolved)
gh api graphql -f query='
  query($owner:String!,$repo:String!,$pr:Int!){
    repository(owner:$owner,name:$repo){
      pullRequest(number:$pr){
        reviewThreads(first:100){
          nodes{ id isResolved isOutdated comments(first:50){ nodes{ id databaseId body path line author{login} } } }
        }
      }
    }
  }' -f owner=$OWNER -f repo=$NAME -F pr=$PR
```

**Build a worklist** of threads where `isResolved=false`. Skip resolved threads. Note `isOutdated=true` threads — the anchor line may have moved; verify before acting.

**Pagination caps**: `reviewThreads(first:100)` truncates at 100 threads, and `comments(first:50)` truncates at 50 per thread. For larger PRs, also request `pageInfo{hasNextPage endCursor}` and re-query with `after:$cursor` until `hasNextPage=false`. If the first page already returns `hasNextPage=true`, you have not seen all threads — do NOT proceed to Phase 3 with a partial worklist.

---

## Phase 3 — Per-thread loop (fan out to subagents)

Use `todowrite` to mark this phase as in_progress.

For each unresolved thread, in order from oldest to newest, **dispatch a resolver subagent** (via `task({ subagent_type: "general", description: "Resolve PR comment thread", prompt: "..." })`) — one subagent invocation per thread, sequentially. Each subagent isolates the read-edit-commit-reply-resolve work in a fresh context, so the parent's window stays clean as you work through 10+ threads.

**Pass to the subagent** (per invocation):

```
PR_NUMBER: <number>
REPO: <owner/repo>
BASE_REF: <base branch name>

THREAD:
  threadNodeId: <GraphQL node id from Phase 2>
  isOutdated: <bool>
  rootCommentId: <REST id of the first comment — for in_reply_to>
  rootCommentDatabaseId: <database id>
  path: <file path or null>
  line: <line number or null>
  author: <github login>
  body: <comment markdown>
  isInline: <true for file-anchored, false for PR-level>
```

**The subagent's contract:**
- Read the file at `path:line` (with the branch-local diff context).
- Classify the comment: `change_request` | `question` | `nit` | `stale` | (sub-decision) `declined`.
- If applicable: edit code, commit (one commit per thread), reply via the right gh API surface, resolve the thread (unless declined).
- Return a structured JSON result.

**Why fan out?** Each thread is a self-contained unit (one comment, one diff slice, one fix, one reply). Reading file context for each one accumulates in the parent's window if done inline; isolating per-thread keeps the parent at a constant context size regardless of PR size.

**Why sequential, not parallel?** All threads commit to the same branch. Parallel commits race on `git index.lock` and blow up the one-commit-per-comment audit trail.

From Acauhi99/opencode-agent-system, MIT.

More from Acauhi99/opencode-agent-system