pr-feedback
This skill fetches pull request review feedback, inline comments, and issue-level comments, then categorizes and prioritizes them based on author reactions and reviewer engagement. Use it when a user needs to review, understand, or address feedback on a pull request, either by auto-detecting the PR number from the current branch or accepting a manual PR reference.
git clone --depth 1 https://github.com/strands-agents/harness-sdk /tmp/pr-feedback && cp -r /tmp/pr-feedback/.agents/skills/pr-feedback ~/.claude/skills/pr-feedbackSKILL.md
# PR Review Feedback Fetch PR review feedback and inline comments, categorize them, and present options to fix. ## Process ### 1. Determine the PR Number Auto-detect from the current branch: ```bash gh pr view --json number -q .number ``` If that fails (detached HEAD, no tracking branch), ask the user for the PR number or URL. ### 2. Fetch All Feedback Use the bundled script to fetch reviews, inline comments, and issue-level comments in one shot: ```bash bash .agents/skills/pr-feedback/fetch-pr-feedback.sh <number> [--repo owner/repo] ``` - Omit `<number>` to auto-detect from the current branch. - Use `--repo` when the PR is in a different repo than the current directory. The script returns JSON with three arrays: - `reviews` — top-level review summaries (non-empty bodies only) - `inline_comments` — unresolved thread comments with `upvotes`/`downvotes` arrays (usernames who reacted), `outdated` flag, and `diffHunk` on the first comment in each thread - `comments` — issue-level comments ### 3. Summarize and Present to the User Read all the feedback, use your judgment to group related items, and present a numbered list of things to address. Keep each item to one line. Put the most impactful items first. Use upvotes, downvotes, and the PR author's own replies to determine priority: - **Upvoted by the PR author**: This signals agreement — recommend fixing it. - **Author replied agreeing** (e.g. "good point", "I'll fix", "makes sense"): Same as an upvote — recommend fixing it. - **Upvoted by other reviewers** (not the author): Signals community agreement the issue matters — lean toward recommending. - **No signal from the author**: Present as a suggestion but don't assume it should be fixed. - **Author replied disagreeing or explaining**: Present for context but mark as "discussed — likely skip". - **Outdated comments**: Group separately at the end — these may have been addressed by subsequent pushes. When presenting the list, annotate items you recommend fixing (based on the signals above) so the user can quickly confirm "all recommended" or cherry-pick. ### 4. Fix What the User Selects Address only the confirmed items. After fixing, briefly note what changed — one line per item. ## Rules - Always auto-detect the PR number before asking the user. - Never fix anything before presenting the list and getting user confirmation. - If the output is too large to parse in one shot, focus on non-outdated comments first.
Assess a published or in-progress documentation page for quality, accuracy, and voice compliance. Use before rewriting a page, during periodic health checks, when community signals point to confusion, or when comparing against competitor docs. Also triggers on "audit this page", "assess the docs", "what's wrong with this page", "check docs quality", "review this doc page".
Identify documentation gaps and prioritize the docs backlog. Use when planning a docs improvement sprint, after signals surface repeated friction, when new SDK features ship without docs, or for periodic health assessment. Also triggers on "plan docs work", "what docs need writing", "prioritize the backlog", "docs health check", "what should we document next".
Review documentation drafts for voice consistency, structure, and terminology before PR submission. Use after completing a draft, when checking if docs are ready to ship, or automatically after docs-writer produces output. Also triggers on "review this draft", "check my docs", "is this ready to ship", "review before merging".
Draft or rewrite Strands Agents documentation pages. Use when writing new doc pages, rewriting pages that failed audit, drafting sections for existing pages, or writing blog posts and release notes about Strands. Also triggers on "write a doc", "draft a page", "rewrite the quickstart", "add a tutorial for X", "document this feature".
Local preview of the strands-agents/devtools `/strands review` agent. Body is the upstream Task Reviewer SOP verbatim — do not paraphrase. Use when the user types `/strands-review`, asks for a "strands review" of a PR, or wants to anticipate what the remote `/strands review` GitHub Action will flag. Findings are close but not identical to the remote agent. Strongly prefer running this skill in a fresh-context subagent rather than inline — the SOP is long and reviewer judgment is more reliable when it isn't entangled with the parent conversation's prior context.
Creates a GitHub pull request using the gh CLI. Use when the user asks to create, open, or submit a PR on GitHub.
Generates pull request titles and descriptions. Use when the user asks to create, open, write, draft, or generate a PR, pull request, or merge request description.