post-code-review-to-pr

Name: post-code-review-to-pr
Author: testdouble

122stars12forks

How to install post-code-review-to-pr?

testdouble/han/post-code-review-to-pr

$npx -y skills add testdouble/han --skill post-code-review-to-pr

Installs into the current project.

Summary

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 witho

Files · 1

View on GitHub

SKILL.md

1	When running a PR code review, follow the process outlined here.
2
3	## Pre-requisites
4
5	- gh CLI: !`which gh 2>/dev/null \|\| echo "not installed"`
6	- jq: !`which jq 2>/dev/null \|\| echo "not installed"`
7
8	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.
9
10	## Project Context
11
12	- current branch: !`git branch --show-current 2>/dev/null \|\| echo unknown`
13	- default branch: !`git symbolic-ref --short refs/remotes/origin/HEAD 2>/dev/null \|\| echo unknown`
14	- changed files: !`gh pr diff --name-only 2>/dev/null \|\| echo "no pr"`
15
16	## Step 1: Validate PR State
17
18	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.
19
20	## Step 2: Run Code Review
21
22	Invoke the `/code-review` skill to perform the full code review. Pass along any user-provided focus areas or context from the original arguments. After /code-review completes, proceed immediately to Step 3 — do not stop here.
23
24	## Step 3: Offer to Post Review to GitHub
25
26	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.
27
28	If the user accepts:
29
30	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`.
31	2. Build the review body from: 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 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.
32	3. Continue to Step 4 — do not post yet.
33
34	## Step 4: Pre-Post Clarity Check
35
36	Because the review body will be publicly visible on the PR, run a clarity pass on the draft before posting.
37
38	1. Write the draft review body to a temporary file (e.g., `/tmp/post-code-review-to-pr-draft.md`) using the Write tool.
39	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. Return a short list of specific edits with before/after text; return an empty list if the review reads well as-is."
40	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.
41	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).
42	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}`.
43	6. On success, report the PR URL. On failure, report the error.
44
45	## Step 5: Offer to Create Fix Plan (Only If Issues Found)
46
47	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 m

People who liked this also viewed

6 picks

Type

post-code-review-to-pr

122stars12forks

View on GitHub

How to install post-code-review-to-pr?

testdouble/han/post-code-review-to-pr

$npx -y skills add testdouble/han --skill post-code-review-to-pr

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	When running a PR code review, follow the process outlined here.
2
3	## Pre-requisites
4
5	- gh CLI: !`which gh 2>/dev/null \|\| echo "not installed"`
6	- jq: !`which jq 2>/dev/null \|\| echo "not installed"`
7
8	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.
9
10	## Project Context
11
12	- current branch: !`git branch --show-current 2>/dev/null \|\| echo unknown`
13	- default branch: !`git symbolic-ref --short refs/remotes/origin/HEAD 2>/dev/null \|\| echo unknown`
14	- changed files: !`gh pr diff --name-only 2>/dev/null \|\| echo "no pr"`
15
16	## Step 1: Validate PR State
17
18	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.
19
20	## Step 2: Run Code Review
21
22	Invoke the `/code-review` skill to perform the full code review. Pass along any user-provided focus areas or context from the original arguments. After /code-review completes, proceed immediately to Step 3 — do not stop here.
23
24	## Step 3: Offer to Post Review to GitHub
25
26	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.
27
28	If the user accepts:
29
30	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`.
31	2. Build the review body from: 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 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.
32	3. Continue to Step 4 — do not post yet.
33
34	## Step 4: Pre-Post Clarity Check
35
36	Because the review body will be publicly visible on the PR, run a clarity pass on the draft before posting.
37
38	1. Write the draft review body to a temporary file (e.g., `/tmp/post-code-review-to-pr-draft.md`) using the Write tool.
39	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. Return a short list of specific edits with before/after text; return an empty list if the review reads well as-is."
40	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.
41	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).
42	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}`.
43	6. On success, report the PR URL. On failure, report the error.
44
45	## Step 5: Offer to Create Fix Plan (Only If Issues Found)
46
47	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 m

People who liked this also viewed

6 picks

Type