chained-pr

Files (1)

• SKILL.md

SKILL.md (first lines)

# 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)
```

1. PR1 targets main, gets reviewed and merged
2. PR2 targets main, but code based on PR1
3. PR3 targets main, but code based on PR2
4. 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)
```

1. Create tracker PR `feature/auth` → draft, targets main, never merged
2. PR #1 targets `feature/auth`, reviewed and merged into tracker
3. PR #2 targets PR #1's branch, reviewed and merged
4. PR #3 targets PR #2's branch, reviewed and merged
5. 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

1. Estimate changed lines and identify independent work units
2. Ask for chain strategy when none is cached and budget is exceeded
3. Create branches/PRs using the chosen strategy only
4. Add **Chain Context** to each PR body (see below)
5. Verify each PR independently: CI, tests, docs, clean diff
6. Keep tracker PR draft/no-merge until all children are reviewed

## Chain Context (add to each PR body)

```markdown
## 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

From LeandroBenjaminL/lend-ai, MIT.

More from LeandroBenjaminL/lend-ai