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:

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

1. 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
2. Render latest action markdown: