القائمة
Sweep the PR for actionable reviewer feedback (top-level comments, inline review comments, review states) and resolve every item before moving to In Review. Use after every push that might have triggered review, and as the gate before transitioning the issue to In Review.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Create a well-formed git commit from the current changes. Use when finalizing staged work, preparing a commit message, or splitting in-progress work into reviewable history.
Capture Playwright screenshots of a user-facing change and embed them in the GitHub PR description via a temporary commit + force-push. Use whenever the workflow asks for proof-of-testing screenshots on a user-facing change.
Manage the single Symphony Workpad comment on a Linear issue — find or bootstrap, update in place, or reset (Rework). Use whenever the workflow needs to read or write the workpad. Includes the GraphQL `commentUpdate` workaround for the known Linear MCP `save_comment` duplication bug.
Squash-merge the issue's PR once it's approved and green. Use only when the issue is in the `Merging` state — Symphony's status router gates entry.
Sync the current branch with origin/main via merge (not rebase) and resolve any conflicts. Use whenever Symphony's workflow says "merge origin/main into the branch" — at Step 1 setup, before push, and as part of the Land procedure.
Push the current branch to origin and ensure a PR exists for it (creating or updating one), with the symphony label applied. Use when the workflow says "push" or "open a PR".
| name | pr-feedback |
| description | Sweep the PR for actionable reviewer feedback (top-level comments, inline review comments, review states) and resolve every item before moving to In Review. Use after every push that might have triggered review, and as the gate before transitioning the issue to In Review. |
In Review for the first time.Todo redispatch lands on a PR that already has comments — sweep before doing new work.Reviewer feedback arrives across three channels — gather all three:
pr=$(gh pr view --json number -q .number)
repo=$(gh repo view --json nameWithOwner -q .nameWithOwner)
gh api --paginate "repos/${repo}/issues/${pr}/comments"
gh api --paginate "repos/${repo}/pulls/${pr}/comments"
gh api --paginate "repos/${repo}/pulls/${pr}/reviews"
--paginate is mandatory: GitHub REST list endpoints page at 30 by default, so a busy PR can silently hide later comments and trick the sweep into declaring "no actionable feedback" when there is.
The Manual QA Plan comment, when present, sharpens UI/runtime coverage — read it before transitioning.
Treat every actionable comment (human or bot, top-level or inline) as blocking until one of these is true:
Mirror each item and its resolution in the workpad's plan so the trail is auditable.
The endpoint for an inline reply is the pulls endpoint (not issues) and in_reply_to must be the numeric review-comment id, not a GraphQL node id:
gh api -X POST "repos/${repo}/pulls/${pr}/comments" \
-f body='<reply text>' \
-F in_reply_to=<numeric-comment-id>
A 404 here usually means the wrong endpoint (you used issues) or insufficient scope.
Per comment, pick one mode and state it in your reply before changing code:
Correctness concerns must be addressed (or validated as inapplicable, with proof). Style/scope concerns can be deferred with a clear reason.
Repeat sweep → fix → reply → re-run validation → push, until zero outstanding actionable comments and PR checks are green on the latest commit. Only then move the issue to In Review.