Claude Skill

gentle-ai-chained-pr

Trigger: PRs over 400 lines, stacked PRs, review slices. Split oversized changes into chained PRs that protect review focus.

LLM Mart · 0 points · 0 views 0 listing impressions 0 install-command copies
Virus-scanned Reviewed automatically before listing.

Full trust report

Download gentleman-programming-gentle-shell-skills_chained-pr-5454832.zip · 3 KB
gentleman-programming/gentle-shell 937 140 forks MIT Updated 5d ago
Part of gentleman-programming/gentle-shell — 12 skills

Install

skills CLI npx skills add https://github.com/Gentleman-Programming/gentle-shell/tree/main/skills/chained-pr
Claude Code claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install gentleman-programming-gentle-shell@llmmart
Git git clone https://github.com/Gentleman-Programming/gentle-shell.git

The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole gentleman-programming/gentle-shell collection as a plugin from our marketplace. Git is the plain clone.

Skill manifest

Activation Contract

Load this skill when a planned PR may exceed 400 changed lines, SDD forecasts 400-line budget risk: High or Chained PRs recommended: Yes, 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.

Hard Rules

  • Split PRs over 400 changed lines unless a maintainer explicitly accepts size:exception.
  • 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.
  • 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.
  • 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 changed lines and focused Keep single PR.
PR >400, each slice can land independently Use Stacked PRs to main.
PR >400, feature must integrate before main Use Feature Branch Chain with tracker.
Generated/vendor/migration diff cannot split cleanly Ask maintainer for size:exception.
No cohesive split fits the budget after one slicing pass Stop; deliver the best split, report the overage and why it cannot shrink further, and recommend size:exception.
SDD provides delivery_strategy Follow it before apply/PR creation.
ODD provides delivery_strategy and chain_strategy Follow them before the next work-unit commit or PR creation.

Execution Steps

  1. Estimate changed lines 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 (additions + deletions), verification plan, and any size:exception rationale.

References

Files (gentle-shell)
  • references
    • chaining-details.md 3.2 KB 
      # Chained PR Details

## Strategy Notes

| | Stacked PRs to main | Feature Branch Chain |
|---|---|---|
| Speed | Each slice can ship in order | Full feature waits for tracker merge |
| Rollback | Revert individual main PRs | Revert/hold the whole feature branch |
| Risk | Partial behavior may land | Nothing lands until the chain completes |
| Complexity | Simpler retarget/rebase flow | Requires tracker and strict diff hygiene |

## Feature Branch Chain

Use when the feature branch accumulates the final integration while child PRs are reviewed as focused slices.

```text
main
 └── feat/my-feature              ← tracker/final integration branch
      ↑ PR #1 base: feat/my-feature
      └── feat/my-feature-01-core
           ↑ PR #2 base: feat/my-feature-01-core
           └── feat/my-feature-02-shared
                ↑ PR #3 base: feat/my-feature-02-shared
                └── feat/my-feature-03-slice
```

Steps:

1. Create the feature/tracker branch from `main`.
2. Open the tracker PR to `main`; mark it draft/no-merge.
3. Create PR #1 from a child branch and target it to the tracker branch.
4. Create each later child branch from the previous PR branch and target it to that parent branch.
5. Merge/integrate children in order; merge the tracker only after the chain is complete.

## Stacked PRs to Main

Use when each slice can land on `main` in order.

```text
main <- PR 1: foundation
          └── PR 2: feature slice built on PR 1
                └── PR 3: docs/tests built on PR 2
```

After a parent PR merges, rebase/retarget the next PR so GitHub shows only the current slice.

## Chain Context Section

Append this section to the repo PR template; do not replace required issue/checklist sections.

```markdown
## Chain Context

| Field | Value |
|-------|-------|
| Chain | <feature or stack name> |
| Tracker PR | <#NNN or "Not needed"> |
| Position | <N of total> |
| Base | `<target branch>` |
| Depends on | <PR/issue/link or "None"> |
| Follow-up | <next PR or "None"> |
| Review budget | <changed lines> / 400 |
| Starts at | <branch, PR, or state this builds on> |
| Ends with | <standalone result delivered by this PR> |

### Chain Overview

```text
main
 └── #NNN Previous PR
      └── 📍 #NNN This PR
           └── #NNN Next PR
```

### Scope
- Includes: <focused unit>
- Excludes: <deferred work>

### Autonomy
- [ ] CI is expected to pass for this PR branch
- [ ] This PR has one deliverable scope
- [ ] This PR can be rolled back without unrelated changes
- [ ] Tests, docs, or manual verification cover this unit
```

## Commands

```bash
gh pr view <PR_NUMBER> --json additions,deletions,changedFiles,title,url
gh pr create --base feat/my-feature --title "feat(scope): focused slice" --body-file pr-body.md
gh pr create --base feat/my-feature-01-core --title "feat(scope): next focused slice" --body-file pr-body.md
```

## Reviewer Guidance

- Ask for a split when a PR exceeds 400 changed lines without `size:exception`.
- Recommend Feature Branch Chain when work must integrate before `main`.
- Recommend stacked PRs when each slice can merge independently.
- Review child PRs against immediate parent branches; a polluted diff is a branching bug.
  • SKILL.md 3.3 KB 
    ---
name: gentle-ai-chained-pr
description: "Trigger: PRs over 400 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 changed lines**, SDD forecasts `400-line budget risk: High` or `Chained PRs recommended: Yes`, 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.

## Hard Rules

- Split PRs over **400 changed lines** unless a maintainer explicitly accepts `size:exception`.
- 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.
- 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.
- 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 changed lines and focused | Keep single PR. |
| PR >400, each slice can land independently | Use Stacked PRs to main. |
| PR >400, feature must integrate before main | Use Feature Branch Chain with tracker. |
| Generated/vendor/migration diff cannot split cleanly | Ask maintainer for `size:exception`. |
| No cohesive split fits the budget after one slicing pass | Stop; deliver the best split, report the overage and why it cannot shrink further, and recommend `size:exception`. |
| SDD provides `delivery_strategy` | Follow it before apply/PR creation. |
| ODD provides `delivery_strategy` and `chain_strategy` | Follow them before the next work-unit commit or PR creation. |

## Execution Steps

1. Estimate changed lines 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 (`additions + deletions`), 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.

Comments (0)

Sign in to join the conversation.

No comments yet.

Reviews (0)

No reviews yet.

Related

Claude Prompt
Tighten-my-prose editing prompt
Claude Skill
Adversarial code-review skill for Claude
Claude Workflow
Deep-research workflow (fan-out + verify)
Claude Skill
Conventional-commit writer for Claude