Installs into .claude/skills of the current project.
Are you the author of Chained Pr?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/alvaroofernaandez-chained-pr)
---
name: chained-pr
description: "Trigger: PRs over 400 production lines, stacked PRs, review slices. Split oversized changes into chained PRs that protect review focus."
license: Apache-2.0
metadata:
author: gentleman-programming
version: "1.0"
---
## Activation Contract
Load this skill when a planned PR may exceed **400 production lines**, SDD forecasts `400-line budget risk: High` or `Chained PRs recommended: Yes`, or the user asks for chained/stacked PRs, review slices, or reviewer-load control.
## Budget Definition
The budget counts **production lines only**: `additions + deletions` over files that
are not tests. **Test files never count against it.**
A budget that charges for tests pushes in the opposite direction to the one it
exists for. Reviewing a test costs a fraction of reviewing the logic it covers, and
a rule that taxes them teaches the author to write fewer.
Not counted: `*.test.*`, `*.spec.*`, and anything under `__tests__/`, `tests/` or
`e2e/`, plus generated files, vendored code and lockfiles.
Measure it, never estimate it. Estimating by eye is how a 611-line PR gets called
"about 400":
```bash
git diff --numstat <base> <head> \
| rg -v '\.(test|spec)\.|/(__tests__|tests|e2e)/|lock\.(json|yaml)$' \
| awk '{a+=$1; d+=$2} END {print a+d}'
```
Deletions count. A commit that moves 300 lines out of one file and into another is
600 lines a reviewer has to read to confirm nothing changed on the way.
## Hard Rules
- Split PRs over **400 production lines** unless a maintainer explicitly accepts `size:exception`.
- Keep each PR reviewable in about **β€60 minutes**.
- Use 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 items in every chained PR.
- Every child PR must include a dependency diagram marking the current PR with `π`.
- In Feature Branch Chain, create a draft/no-merge tracker PR; child PR #1 targets the tracker branch, later children target the immediate parent branch.
- Treat polluted diffs as base bugs: retarget or rebase until only the current work unit appears.
- Do not mix chain strategies after the user chooses one.
## Decision Gates
| Condition | Action |
|---|---|
| PR β€400 production lines and focused | Keep single PR. |
| PR >400 production lines, each slice can land independently | Use Stacked PRs to main. |
| PR >400 production lines, 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. |
## Execution Steps
1. Measure production lines with the command above and identify independent work units.
2. Ask for a chain strategy when none is cached and the budget is exceeded.
3. Create branches/PRs using the chosen strategy only.
4. Add Chain Context to each PR without replacing the repo PR template.
5. Verify each PR independently: CI/tests/docs/manual checks, rollback scope, and clean diff.
6. Keep tracker PR draft/no-merge until all child PRs are reviewed and integrated.
## Output Contract
Return the chosen strategy, PR order, current PR boundary, dependency diagram, review budget (production lines, with the test lines reported separately so the split is visible), verification plan, and any `size:exception` rationale.
## References
- [references/chaining-details.md](references/chaining-details.md) β strategy diagrams, PR body section, branch commands, and reviewer guidance.