Agent skill · 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. Use when a change is too large for one PR, when splitting a long-lived branch into PRs, when deciding whether work needs a planning stage at all, when landing or propagating a fix through a stack, or when every check is green on a stack and the change is still wrong.
What it needs
About 6k tokens when loaded.
What this skill does
PR Stack Workflow 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. Decide whether it needs a stack 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: If the fix is one commit, there is no plan to make. Do not manufacture slices. If you cannot yet write the acceptance check, you are researching, not planning. Do the research, publish it, then plan. 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. Slice by what a reviewer has to hold in their head 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: 1. The bugs first. Anything true on main regardless of the wider change. It is mergeable on day one, it carries no judgment, and landing it early shrinks everything downstream. 2. Defaults and data shape next. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills langfuse/pr-stack-workflow