process-pr

Name: process-pr
Author: aaddrick

120stars16forks

How to install process-pr?

aaddrick/claude-pipeline/process-pr

$npx -y skills add aaddrick/claude-pipeline --skill process-pr

Installs into the current project.

Summary

Process PR based on code review - if approved, create follow-up issues, merge, close; if changes requested, re-run implement-issue

Files · 1

View on GitHub

SKILL.md

1	# Process PR
2
3	Read PR review comments and act accordingly: if approved, create follow-up issues and merge; if changes requested, re-run implementation.
4
5	Announce at start: "Using process-pr to process PR #$1 for issue #$2"
6
7	Arguments:
8	- `$1` — PR number (required)
9	- `$2` — Issue number that the PR addresses (required)
10	- `$3` — Base branch for re-implementation if needed (required)
11
12	Examples:
13	- `/process-pr 142 130 aw-next`
14	- `/process-pr 456 123 main`
15
16	## Process
17
18	```dot
19	digraph process_pr {
20	rankdir=TB;
21	node [shape=box];
22
23	validate [label="1. Validate inputs"];
24	fetch [label="2. Fetch PR & review comments"];
25	check [label="3. Check review status"];
26
27	approved [label="Approved path"];
28	changes [label="Changes requested path"];
29
30	merge [label="4a. Squash merge PR"];
31	comment [label="4b. Comment on issue"];
32	close [label="4c. Close issue"];
33	delete [label="4d. Delete branch"];
34	parse [label="4e. Parse comments for follow-ups"];
35	create_issues [label="4f. Create follow-up issues"];
36
37	rerun [label="5. Re-run /implement-issue"];
38
39	output_success [label="Output: Success summary"];
40	output_rerun [label="Output: Re-implementation started"];
41
42	validate -> fetch -> check;
43	check -> approved [label="approved"];
44	check -> changes [label="changes requested"];
45
46	approved -> merge -> comment -> close -> delete -> parse -> create_issues -> output_success;
47	changes -> rerun -> output_rerun;
48	}
49	```
50
51	Why merge first: Follow-up issues should only be created if the merge succeeds. Creating issues before merge can leave orphaned issues if merge fails (conflict, permissions, etc.). Merging first ensures we only create follow-ups for work that actually landed.
52
53	### Step 1: Validate Inputs
54
55	```bash
56	# Verify PR exists and is open
57	gh pr view $PR_NUMBER --json state,number,title,headRefName,reviews
58
59	# Verify issue exists and is open
60	gh issue view $ISSUE_NUMBER --json state,number,title
61	```
62
63	If validation fails: Stop and report error.
64
65	### Step 2: Fetch PR & Comments
66
67	```bash
68	# Get PR with comments
69	gh pr view $PR_NUMBER --json number,title,state,headRefName,comments
70
71	# Also get the full PR view with comments for parsing
72	gh pr view $PR_NUMBER --repo OWNER/REPO --comments
73	```
74
75	Extract:
76	- All PR comments (for review status and follow-up issue extraction)
77	- PR metadata (title, branch, state)
78
79	### Step 3: Parse Review Status from Comments
80
81	IMPORTANT: Review status is embedded in PR comments by the `implement-issue` skill. Use this explicit algorithm:
82
83	Step 3a: Fetch all PR comments
84
85	```bash
86	# Get comments as JSON array
87	COMMENTS=$(gh pr view $PR_NUMBER --json comments --jq '.comments[].body')
88	```
89
90	Step 3b: Extract status from comments (most recent wins)
91
92	```bash
93	# Parse status using explicit algorithm
94	parse_review_status() {
95	local comments="$1"
96	local status=""
97
98	# Process comments in order (last one wins)
99	while IFS= read -r comment; do
100	# Check for markdown bold format first (preferred)
101	if echo "$comment" \| grep -q '\\Status: APPROVED\\'; then
102	status="APPROVED"
103	elif echo "$comment" \| grep -q '\\Status: CHANGES_REQUESTED\\'; then
104	status="CHANGES_REQUESTED"
105	# Fallback to plain text format
106	elif echo "$comment" \| grep -q 'Status: APPROVED'; then
107	status="APPROVED"
108	elif echo "$comment" \| grep -q 'Status: CHANGES_REQUESTED'; then
109	status="CHANGES_REQUESTED"
110	fi
111	done <<< "$comments"
112
113	echo "$status"
114	}
115
116	REVIEW_STATUS=$(parse_review_status "$COMMENTS")
117	```
118
119	Step 3c: Validate status
120
121	```bash
122	if [ -z "$REVIEW_STATUS" ]; then
123	echo "ERROR: No review status found in PR #$PR_NUMBER comments"
124	echo "Expected: Comment containing 'Status: APPROVED' or 'Status: CHANGES_REQUESTED'"
125	exit 1
126	fi
127
128	echo "Review status: $REVIEW_STATUS"
129	```
130
131	Status priority:
132	1. `Status: APPROVED` (markdown bold - preferred)
133	2. `Status: CHANGES_REQUESTED` (markdown bold - preferred)
134	3. `Status: APPROVED` (plain text - fallback)
135	4. `Status: CHANGES_REQUESTED` (plain text - fallback)
136
137	Multiple reviews: The algorithm processes comments in chronological order. The LAST status found wins, representing the most recent review.
138
139	---
140
141	## If Approved: Merge Path
142
143	### Step 4a: Squash Merge PR
144
145	```bash
146	gh pr merge $PR_NUMBER \
147	--squash \
148	--delete-branch
149	```
150
151	If merge fails:
152	- Log error with reason
153	- Stop - do not proceed to close issue or create follow-ups
154	- Return failure status
155
156	### Step 4b: Comment on Issue
157
158	```bash
159	gh issue comment $ISSUE_NUMBER --body "$(cat <<'EOF'
160	## Completed
161
162	Resolved via PR #$PR_NUMBER (squash merged).
163
164	### Follow-up issues created:
165	- #XXX - Description
166	- #YYY - Description
167
168	(O

People who liked this also viewed

6 picks

Type

requesting-code-reviewUse when completing tasks, implementing major features, or before merging to verify work meets requirementsSkillsJul 2026176k259k
code-reviewSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026158k181k
receiving-code-reviewUse when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performativeSkillsJul 2026146k259k
baoyu-format-markdownFormats plain text or markdown files with frontmatter, titles, summaries, headings, bold, lists, and code blocks. Use when user asks to "format markdown", "beautify article", "add formatting", or imprSkillsJul 202625k24k
code-review-excellenceMaster effective code review practices to provide constructive feedback, catch bugs early, and foster knowledge sharing while maintaining team morale. Use when reviewing pull requests, establishing reSkillsJul 202625k38k
code-review-and-qualityConducts multi-axis code review. Use before merging any change. Use when reviewing code written by yourself, another agent, or a human. Use when you need to assess code quality across multiple dimensiSkillsJul 202618k80k

process-pr

120stars16forks

View on GitHub

How to install process-pr?

aaddrick/claude-pipeline/process-pr

$npx -y skills add aaddrick/claude-pipeline --skill process-pr

Installs into the current project.

Summary

Process PR based on code review - if approved, create follow-up issues, merge, close; if changes requested, re-run implement-issue

Files · 1

View on GitHub

SKILL.md

1	# Process PR
2
3	Read PR review comments and act accordingly: if approved, create follow-up issues and merge; if changes requested, re-run implementation.
4
5	Announce at start: "Using process-pr to process PR #$1 for issue #$2"
6
7	Arguments:
8	- `$1` — PR number (required)
9	- `$2` — Issue number that the PR addresses (required)
10	- `$3` — Base branch for re-implementation if needed (required)
11
12	Examples:
13	- `/process-pr 142 130 aw-next`
14	- `/process-pr 456 123 main`
15
16	## Process
17
18	```dot
19	digraph process_pr {
20	rankdir=TB;
21	node [shape=box];
22
23	validate [label="1. Validate inputs"];
24	fetch [label="2. Fetch PR & review comments"];
25	check [label="3. Check review status"];
26
27	approved [label="Approved path"];
28	changes [label="Changes requested path"];
29
30	merge [label="4a. Squash merge PR"];
31	comment [label="4b. Comment on issue"];
32	close [label="4c. Close issue"];
33	delete [label="4d. Delete branch"];
34	parse [label="4e. Parse comments for follow-ups"];
35	create_issues [label="4f. Create follow-up issues"];
36
37	rerun [label="5. Re-run /implement-issue"];
38
39	output_success [label="Output: Success summary"];
40	output_rerun [label="Output: Re-implementation started"];
41
42	validate -> fetch -> check;
43	check -> approved [label="approved"];
44	check -> changes [label="changes requested"];
45
46	approved -> merge -> comment -> close -> delete -> parse -> create_issues -> output_success;
47	changes -> rerun -> output_rerun;
48	}
49	```
50
51	Why merge first: Follow-up issues should only be created if the merge succeeds. Creating issues before merge can leave orphaned issues if merge fails (conflict, permissions, etc.). Merging first ensures we only create follow-ups for work that actually landed.
52
53	### Step 1: Validate Inputs
54
55	```bash
56	# Verify PR exists and is open
57	gh pr view $PR_NUMBER --json state,number,title,headRefName,reviews
58
59	# Verify issue exists and is open
60	gh issue view $ISSUE_NUMBER --json state,number,title
61	```
62
63	If validation fails: Stop and report error.
64
65	### Step 2: Fetch PR & Comments
66
67	```bash
68	# Get PR with comments
69	gh pr view $PR_NUMBER --json number,title,state,headRefName,comments
70
71	# Also get the full PR view with comments for parsing
72	gh pr view $PR_NUMBER --repo OWNER/REPO --comments
73	```
74
75	Extract:
76	- All PR comments (for review status and follow-up issue extraction)
77	- PR metadata (title, branch, state)
78
79	### Step 3: Parse Review Status from Comments
80
81	IMPORTANT: Review status is embedded in PR comments by the `implement-issue` skill. Use this explicit algorithm:
82
83	Step 3a: Fetch all PR comments
84
85	```bash
86	# Get comments as JSON array
87	COMMENTS=$(gh pr view $PR_NUMBER --json comments --jq '.comments[].body')
88	```
89
90	Step 3b: Extract status from comments (most recent wins)
91
92	```bash
93	# Parse status using explicit algorithm
94	parse_review_status() {
95	local comments="$1"
96	local status=""
97
98	# Process comments in order (last one wins)
99	while IFS= read -r comment; do
100	# Check for markdown bold format first (preferred)
101	if echo "$comment" \| grep -q '\\Status: APPROVED\\'; then
102	status="APPROVED"
103	elif echo "$comment" \| grep -q '\\Status: CHANGES_REQUESTED\\'; then
104	status="CHANGES_REQUESTED"
105	# Fallback to plain text format
106	elif echo "$comment" \| grep -q 'Status: APPROVED'; then
107	status="APPROVED"
108	elif echo "$comment" \| grep -q 'Status: CHANGES_REQUESTED'; then
109	status="CHANGES_REQUESTED"
110	fi
111	done <<< "$comments"
112
113	echo "$status"
114	}
115
116	REVIEW_STATUS=$(parse_review_status "$COMMENTS")
117	```
118
119	Step 3c: Validate status
120
121	```bash
122	if [ -z "$REVIEW_STATUS" ]; then
123	echo "ERROR: No review status found in PR #$PR_NUMBER comments"
124	echo "Expected: Comment containing 'Status: APPROVED' or 'Status: CHANGES_REQUESTED'"
125	exit 1
126	fi
127
128	echo "Review status: $REVIEW_STATUS"
129	```
130
131	Status priority:
132	1. `Status: APPROVED` (markdown bold - preferred)
133	2. `Status: CHANGES_REQUESTED` (markdown bold - preferred)
134	3. `Status: APPROVED` (plain text - fallback)
135	4. `Status: CHANGES_REQUESTED` (plain text - fallback)
136
137	Multiple reviews: The algorithm processes comments in chronological order. The LAST status found wins, representing the most recent review.
138
139	---
140
141	## If Approved: Merge Path
142
143	### Step 4a: Squash Merge PR
144
145	```bash
146	gh pr merge $PR_NUMBER \
147	--squash \
148	--delete-branch
149	```
150
151	If merge fails:
152	- Log error with reason
153	- Stop - do not proceed to close issue or create follow-ups
154	- Return failure status
155
156	### Step 4b: Comment on Issue
157
158	```bash
159	gh issue comment $ISSUE_NUMBER --body "$(cat <<'EOF'
160	## Completed
161
162	Resolved via PR #$PR_NUMBER (squash merged).
163
164	### Follow-up issues created:
165	- #XXX - Description
166	- #YYY - Description
167
168	(O

People who liked this also viewed

6 picks

Type