review-implement-phase

# Review Implement Phase Run only the implementation phase of the review-framework loop: take triaged `will_address` actions, make code changes, commit in logical steps, post GitHub status updates, and update action status. Run commands from this skill directory. All script paths below are relative to it. ## Inputs - Required: - PR URL - existing `review-actions.json` in output dir - Optional: - output directory - scope constraints (specific action IDs or files) If output directory is omitted, derive: `wip/reviews/<owner>_<repo>_pr-<number>/` ## Preconditions `<output-dir>/review-actions.json` must exist and be valid v2. System dependencies required on PATH: - `node` (Node.js) - `gh` (GitHub CLI) If either is missing, halt immediately and ask the user to install it. The implement-phase scripts require only `node` and `gh`. GitHub admin capability must be available before starting implementation: ```bash node ./scripts/check-github-admin-ready.mjs --pr <PR_URL> ``` If missing, instruct user to run: - `/review-fetch-phase <PR_URL> [output-dir]` - `/review-triage-phase <PR_URL> [output-dir]` ## Behavior 1. Read actions JSON and select actionable rows: - `decision: will_address` - `status: pending | in_progress` 2. Preflight GitHub admin capability: - run `check-github-admin-ready.mjs` and fail fast if unavailable 3. Always post standalone comments (**never pending PR reviews**): - When posting progress updates, do **not** create a PR review (draft/pending or otherwise). - Forbidden flows: - `gh pr review --comment ...` - GraphQL `addPullRequestReview`, `addPullRequestReviewComment`, `addPullRequestReviewThread` (this workflow never uses pending reviews) - Allowed flows: - thread replies via `addPullRequestReviewThreadReply` (or wrapper script) - issue comments via `addComment` (or wrapper script) - Before starting implementation: - **Detect pending reviews authored by the acting user** on this PR: `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}'` - 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. - 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. - GitHub allows one pending review per user per PR, so `mine` holds at most one node across all pages. - If one exists, **halt** and clean it up (submit or dismiss) before continuing. - After posting any "On it" / "Done" comment: - **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. - If one exists, the workflow is **blocked** until it is cleaned up. - Implementation requirement: - For `review_thread` targets, always reply using **thread replies** (never inline PR review comments). - If you only have the thread node id, first fetch the thread’s primary comment node id, then call `addPullRequestReviewThreadReply`. - 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. 4. Delegate implementation to: - `./agents/review-implementer.md` 5. Require implementer responsibilities: - make code changes - run relevant checks - create focused commits - post "On it" when starting each action - 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). - use encoded helper scripts for thread admin operations: - `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) - `node ./scripts/resolve-review-thread.mjs --thread-node-id <threadNodeId>` (only for `review_thread` targets) - comments must be posted as individual standalone comments/replies, never as part of a pending review - after each action completion (Done + resolve when applicable), verify no new pending review was created by the acting user - never use inline parser snippets (for example: `python -c`, `node -e`, `ruby -e`, ad-hoc awk/sed JSON parsing) - only set `status: done` after Done (and, for `review_thread` targets, resolve) succeeds - update `review-actions.json` (`status`, `done.doneAt`, `done.summary`, `done.commits`) in the same completion step 6. Render latest action markdown: ```bash node ../review-triage-phase/scripts/render-review-actions.mjs --in <output-dir>/review-actions.json --out <output-dir>/review-actions.md ``` ## Ownership - This phase owns actual fixes plus posting Done and resolving completed threads. - If GitHub thread reply/resolve cannot be performed, the phase is blocked and must not report completion. - 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. ## Output to user Return: - commits created - actions transitioned to done - written artifacts (`review-actions.json`, `review-actions.md`) Suggest next steps: - `/review-fetch-phase <PR_URL> [output-dir]` - `/review-triage-phase <PR_URL> [output-dir]`