chained-pr

1## Activation Contract
2 
3Load this skill when a planned PR may exceed **400 changed lines**, an ODD feature's forecast or running authored changed-line count from work-unit commits exceeds about 400, or the user asks for chained/stacked PRs, review slices, or reviewer-load control.
4 
5## Hard Rules
6 
7- Split PRs over **400 changed lines** unless a maintainer explicitly accepts `size:exception`.
8- The budget constrains how work is **sliced**, never the code itself. Never delete comments, blank lines, docs, or tests, and never compress or restyle code, to fit under the budget.
9- Slicing is bounded: make **one** honest slicing pass. If no cohesive split brings every slice within budget, stop iterating, keep the best cohesive split, and report the final line count with a `size:exception` recommendation.
10- Keep each PR reviewable in about **≤60 minutes**.
11- Use one deliverable work unit per PR; keep tests/docs with the unit they verify.
12- State start, end, prior dependencies, follow-up work, and out-of-scope items in every chained PR.
13- Every child PR must include a dependency diagram marking the current PR with `📍`.
14- 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.
15- Treat polluted diffs as base bugs: retarget or rebase until only the current work unit appears.
16- Do not mix chain strategies after the user chooses one.
17 
18## Decision Gates
19 
20| Condition | Action |
21|---|---|
22…