Skill: chained-pr
Chained PRs. Large changes broken into reviewable chunks that protect reviewer cognitive load.
Activation Contract
Load this skill when:
- A planned PR may exceed 300 changed lines
- SDD forecasts
300-line budget risk: High or Chained PRs recommended: Yes
- The user asks for chained/stacked PRs or review slices
Hard Rules
- Split PRs over 300 changed lines unless a maintainer explicitly accepts
size:exception
- Keep each PR reviewable in ≤60 minutes
- One deliverable work unit per PR; keep tests/docs with the unit they verify
- State start, end, prior dependencies, follow-up work, and out-of-scope in every chained PR
- Every child PR must include a dependency diagram marking the current PR with
📍
- Do not mix chain strategies after the user chooses one
Decision Gates
| Condition |
Action |
| PR ≤300 changed lines and focused |
Keep single PR |
| PR >300, each slice can land independently |
Use Stacked PRs to main |
| PR >300, feature must integrate before main |
Use Feature Branch Chain with tracker |
| Generated/vendor/migration diff cannot split cleanly |
Ask maintainer for size:exception |
SDD provides delivery_strategy |
Follow it before apply/PR creation |
Strategy A: Stacked PRs to Main
main ← PR1 (refactor base)
← PR2 (core logic, base = PR1)
← PR3 (integration, base = PR2)
- PR1 targets main, gets reviewed and merged
- PR2 targets main, but code based on PR1
- PR3 targets main, but code based on PR2
- Each merge updates main, next PR rebases
Strategy B: Feature Branch Chain (with Tracker)
main ←──── feature/auth (tracker PR, draft, no merge)
← feat/auth-validate (PR #1)
← feat/auth-middleware (PR #2, base = PR #1)
← feat/auth-integrate (PR #3, base = PR #2)
- Create tracker PR
feature/auth → draft, targets main, never merged
- PR #1 targets
feature/auth, reviewed and merged into tracker
- PR #2 targets PR #1's branch, reviewed and merged
- PR #3 targets PR #2's branch, reviewed and merged
- When all children are in, merge tracker to main
Critical: child PRs must NEVER target main directly. If GitHub shows previous slices in a child diff, retarget/rebase until the diff is clean.
Execution Steps
- Estimate changed lines and identify independent work units
- Ask for chain strategy when none is cached and budget is exceeded
- Create branches/PRs using the chosen strategy only
- Add Chain Context to each PR body (see below)
- Verify each PR independently: CI, tests, docs, clean diff
- Keep tracker PR draft/no-merge until all children are reviewed
Chain Context (add to each PR body)
## PR Chain
This is PR **2 of 3** in the `{feature}` chain:
- 📍 **PR #2 — {this PR description}** (you are here)
- PR #1: {description} → {link}
- PR #3: {description} → {link}
| Item | Value |
|------|-------|
| Chain strategy | stacked-to-main / feature-branch-chain |
| Review budget | {additions} + {deletions} = {total} changed lines |
| Depends on | {PR #1 link} |
| Blocks | {PR #3 link} |
Output Contract
Return: chosen strategy, PR order, current PR boundary, dependency diagram, review budget, verification plan, and any size:exception rationale.
Anti-patterns
- ❌ Splitting by file type instead of work unit (models/views/controllers → weak split)
- ❌ Child PR diff includes parent's code (polluted diff → retarget/rebase)
- ❌ Mixing stacked-to-main and feature-branch in same chain
- ❌ Tracker PR merged before children are complete
1---2name: chained-pr3description: Splits oversized pull requests into sequential, reviewable chunks under 300 lines using stacked PRs or feature branch chains, with dependency tracking and review budget management.4license: MIT5---67# Skill: chained-pr89Chained PRs. Large changes broken into reviewable chunks that protect reviewer cognitive load.1011## Activation Contract1213Load this skill when:14- A planned PR may exceed **300 changed lines**15- SDD forecasts `300-line budget risk: High` or `Chained PRs recommended: Yes`16- The user asks for chained/stacked PRs or review slices1718## Hard Rules1920- Split PRs over **300 changed lines** unless a maintainer explicitly accepts `size:exception`21- Keep each PR reviewable in ≤60 minutes22- One deliverable work unit per PR; keep tests/docs with the unit they verify23- State start, end, prior dependencies, follow-up work, and out-of-scope in every chained PR24- Every child PR must include a dependency diagram marking the current PR with `📍`25- Do not mix chain strategies after the user chooses one2627## Decision Gates2829| Condition | Action |30|-----------|--------|31| PR ≤300 changed lines and focused | Keep single PR |32| PR >300, each slice can land independently | Use **Stacked PRs to main** |33| PR >300, feature must integrate before main | Use **Feature Branch Chain** with tracker |34| Generated/vendor/migration diff cannot split cleanly | Ask maintainer for `size:exception` |35| SDD provides `delivery_strategy` | Follow it before apply/PR creation |3637## Strategy A: Stacked PRs to Main3839```40main ← PR1 (refactor base)41 ← PR2 (core logic, base = PR1)42 ← PR3 (integration, base = PR2)43```44451. PR1 targets main, gets reviewed and merged462. PR2 targets main, but code based on PR1473. PR3 targets main, but code based on PR2484. Each merge updates main, next PR rebases4950## Strategy B: Feature Branch Chain (with Tracker)5152```53main ←──── feature/auth (tracker PR, draft, no merge)54 ← feat/auth-validate (PR #1)55 ← feat/auth-middleware (PR #2, base = PR #1)56 ← feat/auth-integrate (PR #3, base = PR #2)57```58591. Create tracker PR `feature/auth` → draft, targets main, never merged602. PR #1 targets `feature/auth`, reviewed and merged into tracker613. PR #2 targets PR #1's branch, reviewed and merged624. PR #3 targets PR #2's branch, reviewed and merged635. When all children are in, merge tracker to main6465**Critical**: child PRs must NEVER target main directly. If GitHub shows previous slices in a child diff, retarget/rebase until the diff is clean.6667## Execution Steps68691. Estimate changed lines and identify independent work units702. Ask for chain strategy when none is cached and budget is exceeded713. Create branches/PRs using the chosen strategy only724. Add **Chain Context** to each PR body (see below)735. Verify each PR independently: CI, tests, docs, clean diff746. Keep tracker PR draft/no-merge until all children are reviewed7576## Chain Context (add to each PR body)7778```markdown79## PR Chain8081This is PR **2 of 3** in the `{feature}` chain:82- 📍 **PR #2 — {this PR description}** (you are here)83- PR #1: {description} → {link}84- PR #3: {description} → {link}8586| Item | Value |87|------|-------|88| Chain strategy | stacked-to-main / feature-branch-chain |89| Review budget | {additions} + {deletions} = {total} changed lines |90| Depends on | {PR #1 link} |91| Blocks | {PR #3 link} |92```9394## Output Contract9596Return: chosen strategy, PR order, current PR boundary, dependency diagram, review budget, verification plan, and any `size:exception` rationale.9798## Anti-patterns99100- ❌ Splitting by file type instead of work unit (models/views/controllers → weak split)101- ❌ Child PR diff includes parent's code (polluted diff → retarget/rebase)102- ❌ Mixing stacked-to-main and feature-branch in same chain103- ❌ Tracker PR merged before children are complete
LeandroBenjaminL