PR Pilot — PR Submission & Lifecycle Management

Overview

Submit professional-quality pull requests and manage them through the full review lifecycle until merge (or closure). Covers PR creation, CI monitoring, review response, iteration, and tracking.

Use cases: Open-source contributions, team code reviews, multi-repo PR management, any code submission workflow.

Prerequisites

GitHub CLI must be authenticated — PR creation, review monitoring, and commenting all require it:

CODEBLOCK0

If not configured, ask the user to provide:

1. 1. GitHub username — used for --head {username}:{branch} and PR search
2. GitHub token — run gh auth login or set INLINECODE2

Token is required for: creating PRs, posting comments, checking review status, pushing iterations.

Part 1: Submit the PR

Step 1: Stage & Commit (if not done)

CODEBLOCK1

Step 2: Push to Remote

CODEBLOCK2

Step 3: Write PR Description

Use this structured template. Adapt sections based on PR type and scope.

CODEBLOCK3
{paste test output}
N passed in X.XXs
CODEBLOCK4

Adaptation by PR type

Step 4: Create the PR

CODEBLOCK5

Step 5: Verify

CODEBLOCK6

PR Description Quality Checklist

• - [ ] Links to the issue being fixed (with Closes #N)
• [ ] Explains root cause, not just symptom
• [ ] Describes solution approach and design decisions
• [ ] Includes test results
• [ ] Has file change summary table
• [ ] Addresses backward compatibility

Part 2: Manage the PR Lifecycle

2a. Monitor PR Status

Check status periodically:

CODEBLOCK7

2b. Respond to Reviews

When a reviewer provides feedback, classify and respond:

Pattern 1: Actionable Code Fix

Reviewer: "This should handle the null case" / "Add error handling for X"

Action: Fix code → add test → push → reply.

CODEBLOCK8

Pattern 2: Architecture Concern

Reviewer: "This approach is fundamentally flawed because..."

Action: If fundamental, consider full rearchitecture.

CODEBLOCK9

Steps for major rework:

1. 1. Create new branch from upstream
2. Reimplement with new approach
3. Create new PR referencing the old
4. Close old PR with comment pointing to new one
5. Reply to reviewer on new PR

Pattern 3: Style / Convention Nit

Reviewer: "We use camelCase here" / "Please add docstring"

Action: Quick fix → push → reply.

CODEBLOCK10

Pattern 4: Question / Clarification

Reviewer: "Why did you choose X over Y?"

Action: Explain clearly. If they suggest a better approach, adopt it.

CODEBLOCK11

Pattern 5: Request for Tests

Reviewer: "Can you add a test for the edge case where...?"

Action: Write test → verify → push → reply.

CODEBLOCK12

Iteration Workflow

CODEBLOCK13

2c. Handle CI Failures

CODEBLOCK14

2d. Track Progress

Maintain {workspace}/pr-tracker.md for multi-PR management:

CODEBLOCK15

Status icons:

• - 🟢 Open — Waiting for review
• 🟡 Changes Requested — Needs iteration
• 🔵 Approved — Ready to merge
• 🟣 Merged
• 🔴 Closed (not merged)

Update the tracker after each PR event (creation, review, iteration, merge, close).

Review Response Principles

1. 1. Reply to every comment — even if just "Done" or "Good point, fixed"
2. Thank the reviewer in your first response to a review round
3. Never argue — explain once, then defer to the maintainer
4. Be specific — reference commits, line numbers, test names
5. Respond promptly — within 24-48 hours keeps momentum
6. Update PR description if the approach changed significantly

Output

• - PR URL, CI status verified
• Review responses and iterations
• Updated INLINECODE6

Tips

• - In a development pipeline, this follows dev-test and is the final delivery step.
• For managing a portfolio of PRs, run the status check periodically (or set up an automation).
• When responding to architecture concerns, creating a fresh PR (instead of force-pushing a rewrite) keeps the review history clean and makes reviewers' jobs easier.
• Always run tests locally before pushing review iterations.