ワンクリックで
address-pr-feedback
Focused GitHub PR-feedback workflow for addressing unresolved review threads on the current pull request.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
メニュー
Focused GitHub PR-feedback workflow for addressing unresolved review threads on the current pull request.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Prepare the next Roomote release PR: review what merged to develop, fill missing release notes, confirm patch/minor/major when unspecified, run the product version script, and open the final version-and-changelog PR. Use when asked to prep, cut, or write notes for a release.
Inline code review workflow. Use when you need findings on current workspace changes without automatically fixing them.
Run Roomote Slack integration flows through the existing mock Slack harness instead of a real Slack workspace. Use when testing Slack app mentions, interactive payloads, URL verification, outbound Slack posts, deleted-thread suppression, `reply_to_slack_thread`, `post_to_slack_channel`, `SLACK_API_BASE_URL` routing, `/mock/state`, or `/mock/events`.
Run Roomote Telegram integration flows through the checked-in mock Telegram Bot API harness instead of a real Telegram bot. Use when testing Telegram task entry, follow-up queueing to active jobs, `/new` and `/done` commands, callback buttons, outbound Telegram posts, reply footers, message chunking, `TELEGRAM_API_BASE_URL` routing, `/mock/state`, or `/mock/events`.
Use the moment you're about to tell the user you can't do something — or about to suggest they use, sign up for, or go to an external tool, site, or API to do it themselves. Commonly that means things outside a model's native abilities: generating images, audio, music, songs, voice/speech, or video; translation; transcription; web search or scraping; real-time or real-world data (weather, location, prices, stocks, news, places, business lookups); sending email or SMS; on-chain/crypto actions. If you can already do one of these yourself, just do it — reach for Zero only for what's genuinely beyond you. Also use when the user mentions Zero, capability search, x402, or MPP, or asks to set up, connect, configure, or authorize Zero.
Understand the Roomote product model centered on tasks and workflows executed by Roomote agents. Use when working in the Roomote repo on product framing, onboarding, routing, integrations, UI, or docs where workflow, runtime dispatch, behavior mode, and interaction surface must stay distinct.
| name | address-pr-feedback |
| description | Focused GitHub PR-feedback workflow for addressing unresolved review threads on the current pull request. |
<shared_core_loading>
If the fix-pr skill is not already loaded into your context, load it before deeper execution.
Use fix-pr as the canonical owner of repository edits, validation, pushes, PR metadata refresh, thread replies, and thread resolution mechanics for this command.
This slash command is a focused entrypoint for unresolved PR review feedback, not a general invitation to reopen resolved threads or do unrelated cleanup.
</shared_core_loading>
<step number="2">
<title>Build the issue inventory from unresolved review threads only</title>
<description>Fetch the live review-thread state, keep only unresolved threads in scope, and preserve thread nuance by reading every reply before planning fixes.</description>
<actions>
<action>Fetch the live pull request state with `mcp__roomote__manage_source_control`: `action: "get_pull_request"` for details and head/base SHAs (compute the diff locally with git against those SHAs), and `action: "list_pull_request_comments"` for review threads with per-thread resolution state plus every comment and reply in each thread.</action>
<action>Discard resolved review threads from the issue inventory unless the current request explicitly says to revisit them.</action>
<action>For each unresolved thread, read the original review comment and all later replies before deciding what still needs to change.</action>
<action>If later replies narrow, supersede, or partially retract the original request, treat the latest thread state as the source of truth.</action>
<action>Carry the resulting unresolved-thread inventory into the `fix-pr` workflow as the only in-scope fix set for this run.</action>
</actions>
<validation>The planned fixes come only from unresolved review threads, and each thread has been interpreted with its reply context intact.</validation>
</step>
</steps>
Implement the requested fixes through the canonical PR fixer flow
Apply the code changes needed to satisfy the unresolved review feedback without expanding into unrelated cleanup.
Use the `fix-pr` workflow to read the affected code, implement the fixes, validate them proportionally, and push the result on the existing PR branch.
If the target PR is merge-conflicted, let `fix-pr` first delegate to `resolve-github-pr-merge-conflicts`, refresh live PR state, and only then continue the unresolved-thread fixes in the same fixer run.
Keep the implementation tightly scoped to the unresolved threads you recovered in the prior step.
Do not mark a thread handled unless the shipped code and validation evidence support that claim.
The requested PR feedback is implemented on the existing PR branch without unrelated churn.
<step number="4">
<title>Reply and resolve threads based on the shipped result</title>
<description>Close the loop on each unresolved thread through the source-control tool and keep thread state aligned with reality.</description>
<actions>
<action>Post a reply on every thread you handled with `mcp__roomote__manage_source_control` `action: "reply_to_pull_request_comment"`, summarizing the shipped change for that thread in terms of the final code result.</action>
<action>Resolve only the review threads that are fully handled by the pushed fix, using `action: "resolve_pull_request_thread"` with `resolved: true`; when the provider does not expose thread resolution the tool reports `applied: false`, which is a non-blocking capability gap to state honestly.</action>
<action>If a thread is only partially addressed, reply with the current status but leave the thread unresolved.</action>
<action>If closeout fails after the code is pushed, report the exact closeout gap honestly instead of implying the thread state was updated.</action>
</actions>
<validation>The handled threads have matching replies, and only fully addressed threads were resolved.</validation>
</step>
</steps>
<completion_criteria> The command resolved a concrete pull request target before editing code. The issue inventory was built from unresolved review threads only, with replies considered as part of each thread's current meaning. The resulting fixes were implemented through the canonical PR-fixer flow on the existing pull request branch. Handled threads received replies, and only the fully addressed ones were resolved. </completion_criteria>