resolve-pr-comments

Name: resolve-pr-comments
Author: tobihagemann

22installs29forks

How to install resolve-pr-comments?

tobihagemann/turbo/resolve-pr-comments

$npx -y skills add tobihagemann/turbo --skill resolve-pr-comments

Installs into the current project.

Summary

Evaluate, fix, answer, and reply to GitHub pull request review comments and conversation comments. Handles both change requests (fix or skip) and reviewer questions (explain using reasoning recalled from past Claude Code transcripts). Use when the user asks to \"resolve PR commen

Files · 1

View on GitHub

SKILL.md

1	# Resolve PR Review Comments
2
3	Fetch unresolved review comments from a GitHub PR (inline threads, review-body observations, and issue-comment observations from the PR conversation), evaluate each one, fix or skip based on confidence, answer reviewer questions using recalled implementation reasoning, and reply. Inline threads are answered with thread replies; issue-comment findings are answered with new PR conversation comments. Review-body findings flow through the same evaluate-and-fix pipeline; their outcomes land in the summary because a review body has no destination to post to.
4
5	## Task Tracking
6
7	At the start, use `TaskCreate` to create a task for each step:
8
9	1. Fetch comments
10	2. Triage review bodies and issue comments
11	3. Run `/interpret-feedback` skill
12	4. Split questions and change requests
13	5. Run `/evaluate-findings` skill
14	6. Resolve ambiguities
15	7. Run `/resolve-findings` skill
16	8. Verify fixes
17	9. Run `/answer-reviewer-questions` skill
18	10. Run `/reply-to-pr-threads` skill
19	11. Run `/reply-to-pr-conversation` skill
20	12. Summary
21
22	## Step 1: Fetch Comments
23
24	Auto-detect owner, repo, and PR number from current branch if not provided. Then run `scripts/fetch-pr-data.sh`, which handles full pagination (reviews, review threads, inner comment pages for long threads, issue comments, commits) and emits a single merged JSON document:
25
26	```bash
27	bash <skill-dir>/scripts/fetch-pr-data.sh <owner> <repo> <pr_number>
28	```
29
30	Output shape:
31
32	```jsonc
33	{
34	"meta": { "title", "url", "headRefName", "baseRefName" },
35	"reviewThreads": [ { "id", "isResolved", "isOutdated", "comments": { "nodes": [ { "author", "body", "path", "line", "originalLine", "diffHunk" } ] } } ],
36	"reviews": [ { "author", "body", "state", "submittedAt" } ],
37	"issueComments": [ { "author", "body", "createdAt", "url" } ],
38	"commits": [ { "commit": { "oid", "abbreviatedOid", "message", "committedDate" } } ]
39	}
40	```
41
42	Filter review threads to unresolved only. Filter reviews to those with a non-empty body, excluding `PENDING` state (unsubmitted drafts). Filter issue comments to those with a non-empty body.
43
44	## Step 2: Triage Review Bodies and Issue Comments
45
46	Review bodies and PR conversation comments (issue comments) often pack multiple distinct concerns into one comment. Split each non-empty, non-PENDING review body and each non-empty issue comment into atomic observations, one per paragraph or bullet, so each can be evaluated on its own merits.
47
48	For every observation, check whether a subsequent commit already addresses it. Compare the source timestamp (`submittedAt` for review bodies, `createdAt` for issue comments) against each commit's `committedDate`; only commits after the source was posted can address it. Start with commit messages; read `git show <oid>` only when the message is ambiguous. A commit addresses an observation when its changes clearly resolve that specific concern. Touching the same area is not enough.
49
50	Classify each observation:
51	- Addressed: A subsequent commit resolves it. Record the commit SHA for the Step 12 summary.
52	- Unaddressed: No subsequent commit resolves it. Carry into Step 3, tagged with its `source` (`review-body` or `issue-comment`), the author, the observation text, and (for review bodies) the review state.
53
54	Review-body and issue-comment findings have no `diffHunk`, file path, or line reference. The downstream pipeline handles findings without a code location.
55
56	## Step 3: Run `/interpret-feedback` Skill
57
58	Run the `/interpret-feedback` skill on the union of:
59	- Unresolved inline threads
60	- Unaddressed review-body findings from Step 2
61	- Unaddressed issue-comment findings from Step 2
62
63	Skip AI-reviewer accounts — match by known login (e.g., `coderabbitai`, `copilot-pull-request-reviewer[bot]`), not the `[bot]` suffix alone. Their structured feedback routes directly to `/evaluate-findings`.
64
65	For inline threads, include the `diffHunk` so the interpreters can see the code the reviewer was looking at. For outdated comments where `line` is null, use `originalLine`. For review-body and issue-comment findings, provide the observation text and the PR's changed-file list as context.
66
67	Tag each item with its `source` (`inline-thread`, `review-body`, or `issue-comment`) so later steps can route replies correctly.
68
69	## Step 4: Split Questions and Change Requests
70
71	Classify each interpreted item as either a question or a change request based on the reconciled intent from Step 3.
72
73	- Question — th

People who liked this also viewed

6 picks

Type

resolve-pr-comments

22installs29forks

View on GitHub

How to install resolve-pr-comments?

tobihagemann/turbo/resolve-pr-comments

$npx -y skills add tobihagemann/turbo --skill resolve-pr-comments

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Resolve PR Review Comments
2
3	Fetch unresolved review comments from a GitHub PR (inline threads, review-body observations, and issue-comment observations from the PR conversation), evaluate each one, fix or skip based on confidence, answer reviewer questions using recalled implementation reasoning, and reply. Inline threads are answered with thread replies; issue-comment findings are answered with new PR conversation comments. Review-body findings flow through the same evaluate-and-fix pipeline; their outcomes land in the summary because a review body has no destination to post to.
4
5	## Task Tracking
6
7	At the start, use `TaskCreate` to create a task for each step:
8
9	1. Fetch comments
10	2. Triage review bodies and issue comments
11	3. Run `/interpret-feedback` skill
12	4. Split questions and change requests
13	5. Run `/evaluate-findings` skill
14	6. Resolve ambiguities
15	7. Run `/resolve-findings` skill
16	8. Verify fixes
17	9. Run `/answer-reviewer-questions` skill
18	10. Run `/reply-to-pr-threads` skill
19	11. Run `/reply-to-pr-conversation` skill
20	12. Summary
21
22	## Step 1: Fetch Comments
23
24	Auto-detect owner, repo, and PR number from current branch if not provided. Then run `scripts/fetch-pr-data.sh`, which handles full pagination (reviews, review threads, inner comment pages for long threads, issue comments, commits) and emits a single merged JSON document:
25
26	```bash
27	bash <skill-dir>/scripts/fetch-pr-data.sh <owner> <repo> <pr_number>
28	```
29
30	Output shape:
31
32	```jsonc
33	{
34	"meta": { "title", "url", "headRefName", "baseRefName" },
35	"reviewThreads": [ { "id", "isResolved", "isOutdated", "comments": { "nodes": [ { "author", "body", "path", "line", "originalLine", "diffHunk" } ] } } ],
36	"reviews": [ { "author", "body", "state", "submittedAt" } ],
37	"issueComments": [ { "author", "body", "createdAt", "url" } ],
38	"commits": [ { "commit": { "oid", "abbreviatedOid", "message", "committedDate" } } ]
39	}
40	```
41
42	Filter review threads to unresolved only. Filter reviews to those with a non-empty body, excluding `PENDING` state (unsubmitted drafts). Filter issue comments to those with a non-empty body.
43
44	## Step 2: Triage Review Bodies and Issue Comments
45
46	Review bodies and PR conversation comments (issue comments) often pack multiple distinct concerns into one comment. Split each non-empty, non-PENDING review body and each non-empty issue comment into atomic observations, one per paragraph or bullet, so each can be evaluated on its own merits.
47
48	For every observation, check whether a subsequent commit already addresses it. Compare the source timestamp (`submittedAt` for review bodies, `createdAt` for issue comments) against each commit's `committedDate`; only commits after the source was posted can address it. Start with commit messages; read `git show <oid>` only when the message is ambiguous. A commit addresses an observation when its changes clearly resolve that specific concern. Touching the same area is not enough.
49
50	Classify each observation:
51	- Addressed: A subsequent commit resolves it. Record the commit SHA for the Step 12 summary.
52	- Unaddressed: No subsequent commit resolves it. Carry into Step 3, tagged with its `source` (`review-body` or `issue-comment`), the author, the observation text, and (for review bodies) the review state.
53
54	Review-body and issue-comment findings have no `diffHunk`, file path, or line reference. The downstream pipeline handles findings without a code location.
55
56	## Step 3: Run `/interpret-feedback` Skill
57
58	Run the `/interpret-feedback` skill on the union of:
59	- Unresolved inline threads
60	- Unaddressed review-body findings from Step 2
61	- Unaddressed issue-comment findings from Step 2
62
63	Skip AI-reviewer accounts — match by known login (e.g., `coderabbitai`, `copilot-pull-request-reviewer[bot]`), not the `[bot]` suffix alone. Their structured feedback routes directly to `/evaluate-findings`.
64
65	For inline threads, include the `diffHunk` so the interpreters can see the code the reviewer was looking at. For outdated comments where `line` is null, use `originalLine`. For review-body and issue-comment findings, provide the observation text and the PR's changed-file list as context.
66
67	Tag each item with its `source` (`inline-thread`, `review-body`, or `issue-comment`) so later steps can route replies correctly.
68
69	## Step 4: Split Questions and Change Requests
70
71	Classify each interpreted item as either a question or a change request based on the reconciled intent from Step 3.
72
73	- Question — th

People who liked this also viewed

6 picks

Type