fix-pr-comments
Triage unresolved GitHub PR review comments via `gh`, apply fixes for valid feedback and resolve the thread, or post a reasoned rebuttal for invalid feedback without resolving. Use when the user says "fix-pr-comments", "/fix-pr-comments", "处理PR评论", "修复PR review", or asks to go through PR review comments and address them.
معلومات المصدر
- المستودع
- debugtheworldbot/fix-pr-comments
- آخر نشاط في المصدر
- ٢٢ أبريل ٢٠٢٦ في ١١:٥٢
- لغة SKILL.md المكتشفة
- الإنجليزية
- النجوم
- ٠
- التفرعات
- ٠
خيارات التثبيت
يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.
مراجعة ملفات المصدر
اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.
مستكشف الملفات
4 ملفاتعرض SKILL.md
SKILL.md
تعليمات المصدر · معاينة للقراءة فقط- name
- fix-pr-comments
- description
- Triage unresolved GitHub PR review comments via `gh`, apply fixes for valid feedback and resolve the thread, or post a reasoned rebuttal for invalid feedback without resolving. Use when the user says "fix-pr-comments", "/fix-pr-comments", "处理PR评论", "修复PR review", or asks to go through PR review comments and address them.
# Fix PR Comments
Triage unresolved review threads on a GitHub pull request. Fix what is valid, push them back with a resolve; push back on what is not, with a reasoned reply.
## Workflow
1. **Resolve target PR.** If the user gave a PR number or URL, use it. Otherwise `gh pr view --json number,headRefName,baseRefName,url` to get the PR for the current branch. If there is no PR, tell the user and stop.
2. **List unresolved threads.** Run `scripts/list_threads.sh [PR_NUMBER]` — it prints one JSON object per unresolved thread (`thread_id`, `first_comment_db_id`, `path`, `line`, `diff_hunk`, `author`, `body`, `url`, `comments`). If none, report "no unresolved threads" and stop. Save the JSON to a temp file so the ids can be referenced later without re-fetching.
3. **Sync local branch** with `git fetch origin && git status -sb` so fixes land on the latest code. If the PR branch is not checked out locally, check it out before continuing.
4. **Triage each thread.** For every thread:
- **Read the real code** at `path:line` (and surrounding context) before judging. Do not trust the comment's assumption about what the code does — verify.
- Decide valid vs. invalid using the rubric below.
- Act (see "Act on a thread"), then move to the next.
5. **Batch-commit fixes** as you go. Prefer one commit per thread (or one per small cluster of clearly-related threads) so the review history is readable. Commit message format:
```
<short summary of the fix>
Addresses: <thread url>
```
6. **Push once at the end** with `git push` (never `--force` without asking). If the remote has diverged, `git pull --rebase` first.
7. **Report back** with a compact table: thread URL · verdict (fixed / rebutted) · commit sha or reply preview.
## Validity rubric
A comment is **valid** if any of these hold:
- Points at a real bug, crash path, data loss, or security issue
- Identifies a violation of a project convention that is evidenced in the repo
- Flags a concrete correctness or performance problem with a testable claim
- Improves clarity of code whose intent is genuinely ambiguous
A comment is **invalid** if any of these hold:
- Rests on a premise that the actual code disproves (check the file, not the diff hunk)
- Is a subjective style preference not backed by a lint rule or project convention
- Asks for work out of the PR's declared scope
- Duplicates a concern already addressed elsewhere in the diff
- Suggests a change that would break tests or existing behavior
When uncertain, default to **valid** and fix — but only after verifying against the code. If verification changes your mind, rebut.
## Act on a thread
### Valid → fix + resolve
1. Edit the file(s) to address the comment. Keep the change scoped to what the comment asked for; do not refactor around it.
2. If tests exist and are cheap to run for the touched area, run them.
3. `git add <files> && git commit` with the message format above.
4. `scripts/resolve_thread.sh <thread_id>` to resolve the thread. (Do this *after* the fix is committed, not before — so reviewers can see the linked change when they revisit.)
### Invalid → reply, do not resolve
1. Draft a short, respectful rebuttal that:
- States the specific premise you disagree with
- Cites the code (file:line) or behavior that supports your position
- Offers a path forward if the reviewer still wants a change (e.g. "happy to add a test if you'd like to confirm")
2. Write the body to a temp file to preserve newlines, then:
```
scripts/reply_thread.sh <PR_NUMBER> <first_comment_db_id> <body_file>
```
3. **Do not** call `resolve_thread.sh` — leave the thread open for the reviewer.
## Scripts
- `scripts/list_threads.sh [PR]` — unresolved review threads as JSON lines. Auto-detects PR from current branch if omitted.
- `scripts/resolve_thread.sh <thread_id>` — resolve one thread via GraphQL.
- `scripts/reply_thread.sh <PR> <first_comment_db_id> <body>` — post a reply. `body` is a file path, a literal string, or `-` for stdin.
Thread IDs (`PRRT_...`) are GraphQL node ids and go to `resolve_thread.sh`. Reply needs the REST `databaseId` (integer) of the thread's first comment — both come from `list_threads.sh` output as `thread_id` and `first_comment_db_id`.
## Scope notes
- This skill handles **review threads** (line-anchored comments). General PR issue comments (`gh pr view --comments`) are out of scope — mention them to the user if present but do not auto-reply.
- Never resolve a thread without either committing a fix or getting explicit user approval.
- If the PR has 10+ unresolved threads, surface the count first and ask the user whether to process all or filter (by author, by path, by severity).
عرض على GitHub