structuring-prs

Plan and split pull requests into reviewable single PRs or stacked branches.

3|Updated Apr 2, 2026
One-click install
npx skills add https://github.com/OktayCopurlu/ai-shared --skill structuring-prs-oktaycopurlu
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: structuring-prs
Source: https://github.com/OktayCopurlu/ai-shared/tree/main/skills/structuring-prs
Command: npx skills add https://github.com/OktayCopurlu/ai-shared --skill structuring-prs-oktaycopurlu

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Large or entangled pull requests are hard to review and risky to merge. This Skill helps you decide whether a unit of work should ship as one PR or a stack, and walks you through safely splitting an oversized PR without changing behavior. ## Core Features & Use Cases - One PR or a stack decision: Apply seam tests (each PR must build, pass tests, and review on its own) to decide how to package a ticket's work. - Stacked PR implementation: Branch each PR on the previous one, land bottom-up, and rebase as branches merge. - Splitting an existing PR: Map refactor vs feature hunks with gh pr diff, rebuild entangled refactors from content, verify the feature branch is byte-identical to the original tip with git diff --quiet, and re-point the feature PR's base. - Use Case: You opened a 1,500-line PR mixing a refactor with a new feature. Use this Skill to extract the refactor into its own PR, re-point the feature PR's base, and prove nothing changed behaviorally. ## Quick Start Ask the AI to split my current oversized pull request into a refactor PR and a feature PR using the structuring-prs workflow.

Frequently Asked Questions about structuring-prs

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I split a large pull request into smaller PRs?▼

Map the diff with gh pr diff and git log, marking each hunk as refactor or feature. Create a refactor branch off the original base, then a feature branch on top set to the original tip, and verify it is byte-identical with git diff <orig-tip> --quiet before pushing.

When should I use stacked pull requests instead of one PR?▼

Stack only when it lowers review cost: a behavior-preserving refactor landing under a feature, a risky foundational change merging first, or a slice too big for one review with a real internal seam. Default to one PR for atomic or small changes.

How do I verify a PR split did not change behavior?▼

Set the feature branch tree to the original tip and run git diff <orig-tip> --quiet. An empty diff proves the split only repackaged the work; any non-empty diff means a bad merge resolution that must be fixed before pushing.

What if the refactor commit will not cherry-pick cleanly?▼

Rebuild from content instead of cherry-picking. Take each refactor file from the feature tip with git checkout <tip> -- <file> and hand-edit shared files down to the refactor-only part, since entangled commits often depend on earlier feature lines.

Why does my feature PR still show the refactor changes after splitting?▼

The feature PR's base must be re-pointed to the refactor branch, otherwise its diff still includes the refactor. Use gh pr edit to change the base, or the REST API PATCH .../pulls/<n> with the new base if the CLI is broken.