/post-code-review-to-pr

name: post-code-review-to-pr
description: >
  Run a full pull request review and post review comments directly to the current branch's GitHub PR. Requires the gh
  CLI to be installed and a PR to already exist for the current branch. Use when you want review feedback posted to
  GitHub as PR comments. For local code review without posting to GitHub, use code-review instead. Does not write or
  update PR descriptions — use update-pr-description for that.
argument-hint: "[optional context about the PR or areas to focus on]"
allowed-tools:
  Bash(jq *), Bash(gh *), Bash(git *), Bash(make *), Bash(npm *), Read, Write, Grep, Glob, Skill, Agent,
  Bash(bash "${CLAUDE_PLUGIN_ROOT}/scripts/han-config-dir.sh")

When running a PR code review, follow the process outlined here.

Pre-requisites

• gh CLI: !`which gh 2>/dev/null || echo "not installed"`
• jq: !`which jq 2>/dev/null || echo "not installed"`

If `gh` is not found, inform the user it must be installed and configured; if `jq` is not found, inform the user it must be installed. In either case, immediately stop.

Project Context

• current branch: !`git branch --show-current 2>/dev/null || echo unknown`
• default branch: !`git symbolic-ref --short refs/remotes/origin/HEAD 2>/dev/null || echo unknown`
• changed files: !`gh pr diff --name-only 2>/dev/null || echo "no pr"`
• personal config directory: !`bash "${CLAUDE_PLUGIN_ROOT}/scripts/han-config-dir.sh" 2>/dev/null || echo "$HOME/.claude"`
• project .han/config.md: !`cat .han/config.md 2>/dev/null || echo ""`

As your first action, use the Read tool on `.han/config.md` inside the `personal config directory` path above. A read that returns no file is no personal configuration: continue silently. When that file or the `project .han/config.md` probe supplies content, apply it per [config-rule.md](../../references/config-rule.md), which governs precedence between the two files, relative-path resolution, and what to do with a file that reads but cannot be used.

Step 1: Validate PR State

If `changed files` is empty or reads `no pr`, or `gh pr view --json number,url` fails, inform the user no reviewable PR exists for the current branch and stop.

Step 2: Run Code Review

Invoke the `/code-review` skill to perform the full code review. Pass along any user-provided focus areas or context from the original arguments.

`/code-review` writes its report to a file and names the path in its closing message; it does not print the review into the conversation. **Capture that path** — Step 3 reads the report from it. After /code-review completes, proceed immediately to Step 3 — do not stop here.

Step 3: Offer to Post Review to GitHub

Ask the user whether they'd like to post the review to the PR on GitHub using `AskUserQuestion` with options "Yes, post the review to GitHub" and "No, just the local review". If the user declines, proceed to Step 5.

If the user accepts:

1. Gather PR metadata by running `${CLAUDE_SKILL_DIR}/scripts/pr-metadata.sh`, which outputs JSON with `owner_repo`, `pr_number`, `head_sha`, `pr_author_login`, and `current_user_login`. 2. Read the report file at the path captured in Step 2, then build the review body from it: Review Summary table, Review Recommendation, and all findings organized by severity, plus any optional sections that are present. Treat every section other than the Review Summary table and the Review Recommendation as optional — the code-review skill renders a section only when it has content, so a section (the Review Coverage section, the What's Good section, an absent severity section on a clean review, the Security Vulnerabilities section, the Remediation note) may simply not be there. Include each section when present and omit it without error or an empty heading when absent. **Review Coverage always crosses when present.** It appears only when no specialist read the change, and a reviewer on the pull request is the reader who most needs to know that. 3. Continue to Step 4 — do **not** post yet.

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 fi