Menú
Used to read PR comments on github and act on them
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
Post or update a comment on a Linear ticket using the Linear MCP server. Accepts a ticket ID (e.g. ENG-123), a Linear ticket URL, or a direct link to an existing comment. Works for both human-authored comments and agent-generated summaries.
Creates a Linear document (the Documents feature, distinct from issues/projects) from context in the current conversation, a plan, or a file. Use when the user wants to write up a doc, spec, RFC, or notes page in Linear and attach it to a team, project, initiative, cycle, or issue.
Used to run githooks, perform code & plan reviews with expert critics, and commit/push verified changes
Creates a Linear project under an initiative from a draft list of tickets, clarifies ambiguity with the human, then creates the project and each ticket via /create-linear-ticket. Use when the user wants to stand up a new project in Linear from a plan, doc, or ticket list.
Used to build and execute an approved implementation plan by spinning up agents
Used to gather requirements, clarify scope, and create implementation plans for new feature requests or bug fixes
| name | address-pr-comments |
| description | Used to read PR comments on github and act on them |
| disable-model-invocation | false |
Fetch the open PR for the current branch. If no PR exists, notify the human and stop. If multiple PRs exist, ask the human to select one.
Fetch all unresolved comments. Separate human comments from bot/automated comments (Copilot, github-actions, etc.).
Human comments — assess each:
Present this plan to the human — what will be changed, what needs discussion, and what is stale. Wait for explicit approval before proceeding. This is the first approval gate; complete it before moving to step 4.
Bot/automated comments (Copilot, github-actions, etc.) — these require explicit human approval before ANY action. Never auto-implement bot suggestions. Skip this step entirely if there are no bot comments. For each bot thread, classify it using the first matching category:
Write a markdown triage file to /tmp/{PR_NUMBER}.md (where {PR_NUMBER} is the numeric PR number from the PR URL or gh pr view output). If the file already exists from a prior run, overwrite it entirely. The file MUST contain a table with these columns:
| Author | Thread ID | File:Line | Summary | Agent Assessment | Decision |
|---|
list-unresolved-threads.shimplement | ignore | discuss | deferTell the human the file path and instruct them to open it, fill in the Decision column, and return it. Do not implement or resolve any bot threads until the human returns the filled-in file. If the human never returns the file or says to skip, proceed without addressing bot comments.
Once the human returns the filled-in file, act on each thread according to its Decision value:
implement: Make the code change. Then reply inside the thread referencing the commit SHA where the fix landed, and resolve the thread.ignore: Reply inside the thread explaining that the suggestion was reviewed and intentionally not adopted (one sentence why). Then resolve the thread.discuss: Reply inside the thread with the agent's assessment and any relevant context to move the conversation forward. Do not resolve — leave the thread open for human follow-up.defer: Reply inside the thread explaining that the suggestion is valid but being deferred (include a ticket link or note if one exists). Then resolve the thread.Take actions based on human input from both approval gates. For discussion-type comments, post a reply inside the review thread (not as a top-level PR comment) using gh api repos/{owner}/{repo}/pulls/{pull_number}/comments -X POST -f body="..." -f in_reply_to={comment_id}, where {comment_id} is the numeric ID of the original inline comment (from the gh api .../pulls/{pr}/comments response). Never use gh pr comment for thread replies — that posts at the top level.
Identity disclosure (required on every posted comment): Any comment posted on behalf of the human MUST begin with:
_Posted by {your identity} on behalf of @<github-handle>._(using your identity from CLAUDE.md), then the reply body. Never omit this line.
Run /critique to ensure changes are reviewed, committed, and pushed.
Attempt to resolve addressed PR comment threads. The gh CLI still has no native resolve command, so use the helper scripts in this skill's folder:
# List unresolved threads (tab-separated: id, path:line, author, snippet)
$HOME/.claude/skills/address-pr-comments/list-unresolved-threads.sh <pr-number|pr-url> [--repo OWNER/REPO]
# Resolve specific threads by ID
$HOME/.claude/skills/address-pr-comments/resolve-threads.sh <thread-id> [<thread-id>...]
# Or resolve every unresolved thread on a PR
$HOME/.claude/skills/address-pr-comments/resolve-threads.sh --all <pr-number|pr-url> [--repo OWNER/REPO]
Always use the absolute paths above — these scripts live in $HOME/.claude/skills/, not in the user's repo. Only resolve threads whose feedback you actually addressed. Skip discussion-type threads that are still waiting on a human reply. Resolution requires triage/write permission on the repo — report any failures to the human.
Re-request review from the original commenters if they had requested changes or notify them via a PR comment that their feedback has been addressed. Any notification comment MUST also open with the same identity disclosure described in step 5.
After pushing, check CI status using gh pr checks. If any checks are failing, invoke /resolve-ci-failures to investigate and fix them.
This skill covers one round of comments. If new comments arrive after this round is complete, the human should invoke this skill again.