review-implement-phase

name	review-implement-phase
description	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.
argument-hint	[pr-url] [output-dir]

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:

• gh (GitHub CLI)

If gh is missing, halt immediately and ask the user to install it. The implement-phase scripts no longer depend on jq.

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.
     • If any exist, halt and clean them up (submit or dismiss) before continuing.
   • After posting any "On it" / "Done" comment:
     • Re-check for pending reviews authored by the acting user.
     • If any exist, the workflow is blocked until they are 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:

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]