Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →langfuse/pr-stack-workflow
Split a large change into a chained stack of small, independently reviewable pull requests, and verify each branch on its own.
Passed 20 of 23 test cases with the skill, and 8 of 23 without it.
and 17 more in the full report
12 fixed8 passed either way3 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 12 test cases the skill fixed. Same model, same prompt, with and without the skill.
I am writing the description for PR #3 in a 5-PR chain. PR #3 is based on branch feat/part-2, which corresponds to PR #18200 on GitHub. Provide the exact header line that must appear in PR #3's body to declare its position, base PR, and landing behavior.
| Checked | Without skill | With skill |
|---|---|---|
| Provides the header line using the exact structure '3/5, based on #18200. Base retargets to main when #18200 lands.' | Missed | Passed |
The instructions your model reads when the skill loads.
Use this for any change too large to review as one pull request: deciding whether to stack at all, where to cut the slices, the mechanics that keep a stack reviewable, and how to verify each branch instead of only the tip.
Branch names, commit and PR-title conventions, and how to handle bot review
threads live in git-workflow. Read that first; this skill does not restate it.
A stack costs real time, because every landing forces a base move plus a merge down the rest of the chain. Pay that only when one of these is true.
| Stack it | Ship it as one PR |
|---|---|
| You cannot describe the diff in one sentence without the word "and" | One symptom, one cause |
| It changes a default, or a shape users already have persisted, so it needs a migration decision | The behavior is new and nobody has state in it |
| Someone will ask "why" and the answer is evidence: numbers, screenshots, a competitor's UI | The bug report is the justification |
| It touches a shared component other surfaces consume | The blast radius is one screen |
| Verification is a click path, not an assertion | An existing test proves it |
Two consequences:
Keep the stack short. Every landing costs another round of retarget-and-merge, so length is a running cost you pay until the last PR is in.
Not by file, not by directory, not by frontend versus backend. A slice is right when a reviewer can state what it does, and check it, without loading any other slice. Practical shapes, in the order they should land:
main regardless of the wider change.
It is mergeable on day one, it carries no judgment, and landing it early
shrinks everything downstream.test cases passed, vs 8 / 23 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.