agentleFS
Sign inStart free
AndyTechnologiesAndyTechnologies/my-own-skills/skills/chained-pr/SKILL.md

chained-pr

Skill0 starsChanged 38 days agoApache-2.0View on GitHub

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

3 other projects use a version of this, 1 of them edited.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

10 rules. About 0 are common, 8 are distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈8

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Keep each PR reviewable in about ≤60 minutes.

    line 19
  2. Distinctive:

    Use one deliverable work unit per PR.

    line 20
  3. Very specific:

    Every child PR must include a dependency diagram marking the current PR with 📍.

    line 22
  4. Distinctive:

    Treat polluted diffs as base bugs: retarget or rebase until only the current work unit appears.

    line 24
  5. Distinctive:

    Do not mix chain strategies after the user chooses one.

    line 25
  6. Distinctive:

    Ask for a chain strategy when none is cached and the budget is exceeded.

    line 42
  7. Distinctive:

    Create branches/PRs using the chosen strategy only.

    line 43
  8. Distinctive:

    Add Chain Context to each PR without replacing the repo PR template.

    line 44
  9. Very specific:

    Verify each PR independently: CI/tests/docs/manual checks, rollback scope, and clean diff.

    line 45
  10. Distinctive:

    Keep tracker PR draft/no-merge until all child PRs are reviewed and integrated.

    line 46

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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

ConditionAction
PR ≤400 changed lines and focusedKeep single PR.
PR >400, each slice can land independentlyUse Stacked PRs to main.
PR >400, feature must integrate before mainUse Feature Branch Chain with tracker.
Generated/vendor/migration diff cannot split cleanlyAsk maintainer for size:exception.
No cohesive split fits the budget after one slicing passStop; deliver the best split, report the overage and why it cannot shrink further, and recommend size:exception.
SDD provides delivery_strategyFollow it before apply/PR creation.
ODD provides delivery_strategy and chain_strategyFollow 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 — strategy diagrams, PR body section, branch commands, and reviewer guidance.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free