Split changes exceeding 400 lines into linked pull requests with clear boundaries and dependencies. Choose a chain structure, keep tests and documentation with each work unit, and document review order, verification plans, and justified size exceptions.
Trigger: PRs over 400 lines, stacked PRs, review slices. Split oversized changes into chained PRs that protect review focus.
Review the instructions the agent will receive before you install.
Load 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.
size:exception.size:exception recommendation.📍.| 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. |
ODD provides delivery_strategy and chain_strategy | Follow them before the next work-unit commit or PR creation. |
Return the chosen strategy, PR order, current PR boundary, dependency diagram, review budget (additions + deletions), verification plan, and any size:exception rationale.
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Prepare pull requests by checking approved issue links, change-type labels, and required automated checks. Draft the repository’s PR template using observed test results, while leaving commits, pushes, PR creation, and merging under human control.
Structure guides, READMEs, design documents, and pull request descriptions so readers can find answers quickly. Put outcomes first, introduce details gradually, and use examples, tables, and checklists to support understanding and review.
Draft clear, considerate comments for code reviews, issue replies, and team updates. Put the actionable point first, explain technical reasons when needed, and give a concrete next step while matching the conversation’s language.
Create and verify gentle-ai journeys, which are scripted sequences of product actions. Check their declarations separately from actual execution, review outdated expectations after behavior changes, and record execution results for pull requests.
Prepare Gentle AI changes for review by linking approved issues, following branch and commit naming rules, and drafting pull requests with observed test results. Check change size and required automated checks before claiming readiness.
Split large code changes into linked pull requests, each with a focused scope. Organize their order, dependencies, and verification steps so reviewers can assess one unit of work at a time.