review-implement-phase

1---2name: review-implement-phase3description: Implements triaged review actions, commits focused fixes, and posts Done plus resolves threads. Use when the user wants only the implementation phase of the review-framework workflow.4argument-hint: "[pr-url] [output-dir]"5---6 7# Review Implement Phase8 9Run only the implementation phase of the review-framework loop:10 11take triaged `will_address` actions, make code changes, commit in logical steps, post GitHub status updates, and update action status.12 13Run commands from this skill directory. All script paths below are relative to it.14 15## Inputs16 17- Required:18  - PR URL19  - existing `review-actions.json` in output dir20- Optional:21  - output directory22  - scope constraints (specific action IDs or files)23 24If output directory is omitted, derive:25 26`wip/reviews/<owner>_<repo>_pr-<number>/`27 28## Preconditions29 30`<output-dir>/review-actions.json` must exist and be valid v2.31 32System dependencies required on PATH:33 34- `node` (Node.js)35- `gh` (GitHub CLI)36 37If either is missing, halt immediately and ask the user to install it. The implement-phase scripts require only `node` and `gh`.38 39GitHub admin capability must be available before starting implementation:40 41```bash42node ./scripts/check-github-admin-ready.mjs --pr <PR_URL>43```44 45If missing, instruct user to run:46 47- `/review-fetch-phase <PR_URL> [output-dir]`48- `/review-triage-phase <PR_URL> [output-dir]`49 50## Behavior51 521. Read actions JSON and select actionable rows:53   - `decision: will_address`54   - `status: pending | in_progress`552. Preflight GitHub admin capability:56   - run `check-github-admin-ready.mjs` and fail fast if unavailable573. Always post standalone comments (**never pending PR reviews**):58   - When posting progress updates, do **not** create a PR review (draft/pending or otherwise).59   - Forbidden flows:60     - `gh pr review --comment ...`61     - GraphQL `addPullRequestReview`, `addPullRequestReviewComment`, `addPullRequestReviewThread` (this workflow never uses pending reviews)62   - Allowed flows:63     - thread replies via `addPullRequestReviewThreadReply` (or wrapper script)64     - issue comments via `addComment` (or wrapper script)65   - Before starting implementation:66     - **Detect pending reviews authored by the acting user** on this PR:67       `gh api graphql -f query='query($owner:String!,$repo:String!,$pr:Int!,$before:String){viewer{login} repository(owner:$owner,name:$repo){pullRequest(number:$pr){reviews(last:100,states:PENDING,before:$before){pageInfo{hasPreviousPage startCursor} nodes{id author{login}}}}}}' -F owner=<owner> -F repo=<repo> -F pr=<number> --jq '.data as $d | $d.repository.pullRequest.reviews | {mine: [.nodes[] | select(.author.login == $d.viewer.login)], pageInfo}'`68     - The `author.login` filter matters: another user's pending review is not yours to submit or dismiss, and must not block this workflow. `--jq` is `gh`'s built-in filter and needs no `jq` binary.69     - The filter keeps `pageInfo` beside the matches, because an empty `mine` alone cannot tell "no pending review" from "the match is on an earlier page". Read both: while `mine` is empty and `pageInfo.hasPreviousPage` is true, re-run the query with `-f before=<pageInfo.startCursor>`. Conclude there is no pending review only when `mine` is empty and `hasPreviousPage` is false.70     - GitHub allows one pending review per user per PR, so `mine` holds at most one node across all pages.71     - If one exists, **halt** and clean it up (submit or dismiss) before continuing.72   - After posting any "On it" / "Done" comment:73     - **Re-check for a pending review authored by the acting user**, with the same filtered query and the same paging rule: keep reading `pageInfo` until `mine` is non-empty or `hasPreviousPage` is false.74     - If one exists, the workflow is **blocked** until it is cleaned up.75   - Implementation requirement:76     - For `review_thread` targets, always reply using **thread replies** (never inline PR review comments).77       - If you only have the thread node id, first fetch the thread’s primary comment node id, then call `addPullRequestReviewThreadReply`.78     - For `pull_request_review` targets (review-body findings, `PRR_…` node ids), inline replies are not possible. `post-review-thread-reply.mjs` auto-detects this and posts a top-level PR issue comment instead (response `kind: "issue_comment"`); there is no thread to resolve, so the implementer skips `resolve-review-thread.mjs` for these and records the issue-comment id in the action's `done` record.794. Delegate implementation to:80  - `./agents/review-implementer.md`815. Require implementer responsibilities:82   - make code changes83   - run relevant checks84   - create focused commits85   - post "On it" when starting each action86   - post "Done" when finished (universal); resolve the thread **only when `target.kind === "review_thread"`** and a `threadNodeId` is available. `pull_request_review` targets have no inline thread, so the implementer skips the resolve step for them and records the issue-comment id in the action's `done` record (per behavior step 3).87   - use encoded helper scripts for thread admin operations:88     - `node ./scripts/post-review-thread-reply.mjs --repo <owner>/<repo> --pr <number> --comment-node-id <primaryCommentNodeId> --body "<text>"` (works for both `review_thread` and `pull_request_review` — auto-detects node kind)89     - `node ./scripts/resolve-review-thread.mjs --thread-node-id <threadNodeId>` (only for `review_thread` targets)90   - comments must be posted as individual standalone comments/replies, never as part of a pending review91   - after each action completion (Done + resolve when applicable), verify no new pending review was created by the acting user92   - never use inline parser snippets (for example: `python -c`, `node -e`, `ruby -e`, ad-hoc awk/sed JSON parsing)93   - only set `status: done` after Done (and, for `review_thread` targets, resolve) succeeds94   - update `review-actions.json` (`status`, `done.doneAt`, `done.summary`, `done.commits`) in the same completion step956. Render latest action markdown:96 97```bash98node ../review-triage-phase/scripts/render-review-actions.mjs --in <output-dir>/review-actions.json --out <output-dir>/review-actions.md99```100 101## Ownership102 103- This phase owns actual fixes plus posting Done and resolving completed threads.104- If GitHub thread reply/resolve cannot be performed, the phase is blocked and must not report completion.105- If comments were accidentally posted as a pending review, the phase is blocked until the pending review is explicitly submitted or dismissed and the action comments are re-posted as standalone comments.106 107## Output to user108 109Return:110 111- commits created112- actions transitioned to done113- written artifacts (`review-actions.json`, `review-actions.md`)114 115Suggest next steps:116 117- `/review-fetch-phase <PR_URL> [output-dir]`118- `/review-triage-phase <PR_URL> [output-dir]`119