chained-pr

Split oversized pull requests into chained PR slices with dependency diagrams.

2|Updated Jul 29, 2025

Search Tags:#code review #pull request #github #branching strategy #release planning #dependency graph #diff hygiene

Ready to run

npx skills add https://github.com/kurojs/EnderDots --skill chained-pr-kurojs

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: chained-pr
Source: https://github.com/kurojs/EnderDots/tree/main/.config/opencode/skills/chained-pr
Command: npx skills add https://github.com/kurojs/EnderDots --skill chained-pr-kurojs

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

It prevents reviewer overload and stalled merges by breaking large pull requests into smaller chained PRs that keep each review focused and time-bounded.

Core Features & Use Cases

400-line guardrail: Enforces a changed-lines budget so diffs stay reviewable unless a maintainer grants a size:exception.
Chained strategy selection: Guides when to use Stacked PRs to main versus a Feature Branch Chain with a draft/no-merge tracker.
Clean diff and dependency hygiene: Requires explicit dependency diagram context for each child PR and treats polluted diffs as base bugs to be retargeted/rebased.

Quick Start

Ask the AI to generate a chained-pr plan that splits your PR exceeding 400 changed lines into reviewable slices using a feature-branch chain with a draft tracker, including PR order, dependency diagram, and a verification plan.

Frequently Asked Questions about chained-pr

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

FAQPage Schema

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

To split a large pull request, you break it into chained PR slices with explicit dependency context. This enforces a changed-lines budget and applies strict branch rules to keep each review focused and under 60 minutes.

When should I use stacked PRs versus a feature branch chain?▼

Use stacked PRs to main for sequential landability, or a feature branch chain with a draft tracker for integration-heavy work. Choosing the right chained strategy keeps diffs clean and ensures each child PR lands safely.

What is a good line limit for code review before splitting a GitHub pull request?▼

A 400-line limit is a strong guardrail for code review before splitting a GitHub pull request. Exceeding this changed-lines budget requires a size exception from a maintainer to prevent reviewer overload and stalled merges.

How do I handle dependency diagrams when creating chained pull requests?▼

When creating chained pull requests, you must generate a dependency diagram marking the current PR with 📍. This explicit dependency context tracks parent-child relationships and treats polluted diffs as base bugs to be retargeted.

Does a chained PR strategy work for integration-heavy feature work?▼

Yes, a chained PR strategy works for integration-heavy feature work by utilizing a tracker branch. This approach maintains a clean diff and dependency hygiene while keeping each deliverable isolated within strict review boundaries.

Why do my pull requests keep getting stalled during code review?▼

Pull requests get stalled during code review because oversized diffs cause reviewer overload. Breaking large changes into chained PR slices with a 400-line limit keeps each review focused, time-bounded, and easier to merge.