Post Code Review To PR

Step 4: Pre-Post Clarity Check

Because the review body will be publicly visible on the PR, run a clarity pass on the draft before posting.

Match the body's length to what the review found. Every finding earns its place by naming a specific problem at a specific location. Skip filler sections, a restated summary of the diff, and boilerplate the reader can see for themselves on the PR. Three sections are exempt from that length-matching and are never cut or shortened: the Review Summary table, the Review Recommendation, and the Review Coverage section. Review Coverage names no problem at any location by construction; it says which coverage the review did not have, and deleting it as filler would hide that from the widest audience the review reaches. Stay inside what the review covered: this step edits wording and severity, and never adds a finding /code-review did not raise.

1. Write the draft review body to a temporary file (e.g., /tmp/post-code-review-to-pr-draft.md) using the Write tool.
2. Launch a single han-core:junior-developer agent in artifact-review mode with the prompt: "You are reviewing the text of a code review that is about to be posted publicly on a GitHub pull request. The review is at {draft_path}. Do not re-review the code — review the review. Flag findings whose wording is unclear, severity is mis-assigned (CRIT used where WARN would be accurate, or vice versa), language is accusatory or blaming rather than evidence-based, or file_path:line_number references are missing or invalid. Leave the Review Summary table, the Review Recommendation, and any Review Coverage section as they are; they are not findings and are not subject to the length-matching bar. Return a short list of specific edits with before/after text; return an empty list if the review reads well as-is."
3. Apply every actionable edit the agent returns. If the agent raises a severity-assignment issue, adjust the finding's task ID and the Review Summary table to match.
4. Generate a unique temp file path by running ${CLAUDE_SKILL_DIR}/scripts/create-review-tempfile.sh. Write the final, edited review body to that path using the Write tool (not Bash).
5. Post based on authorship: If pr_author_login matches current_user_login (self-authored PR), post as a PR comment (GitHub rejects formal reviews from PR authors) by running ${CLAUDE_SKILL_DIR}/scripts/post-pr-comment.sh {pr_number} {temp_file_path}. If they differ, determine event type (REQUEST_CHANGES if any CRIT or WARN findings exist, COMMENT if only SUGG) and post as a formal review by running ${CLAUDE_SKILL_DIR}/scripts/post-pr-review.sh {owner/repo} {pr_number} {head_sha} {event_type} {temp_file_path}.
6. On success, report the PR URL. On failure, report the error.

Step 5: Offer to Create Fix Plan (Only If Issues Found)

If any Critical or Warning issues were identified, ask the user using AskUserQuestion — "Would you like me to create a plan to fix the identified issues?" with options "Yes, create a fix plan" and "No, just the review". If yes, enter plan mode and create a detailed implementation plan listing each Critical and Warning item by task ID, with specific code changes, file paths, and line numbers, ordered by priority (Critical first). If no Critical or Warning issues were found, the review is complete — suggestions alone do not warrant a fix plan.