You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
## Summary
{brief_description}
## Related Issue
Addresses {issue_identifier} ({issue_url})
## Stack Context
This PR is part of a stacked PR workflow:
-**Stack position:** {position}/{total_prs}
-**Base:** {base_pr_link or "main"}
-**Next in stack:** {next_pr_link or "none (top of stack)"}
## Stack Overview
{list_all_prs_in_stack}
## Changes
{detailed_changes}
## Test Plan
{test_plan}
## Dependencies
{list_of_blocking_issues_if_any}
Rebase Workflow After Bottom PR Merges
When the bottom PR in the stack merges to main:
# 1. Update local main
git checkout main
git pull origin main
# 2. Update next PR's base to main
gh pr edit <next-pr-number> --base main
# 3. Rebase next branch onto main
git checkout <next-branch>
git rebase main
git push --force-with-lease origin <next-branch># 4. Repeat for remaining PRs in stack# - Next PR now targets main# - Following PRs still target their immediate predecessor# - Continue this process as each PR merges
Merge Conflict Resolution
If rebase encounters conflicts:
Identify conflicting files
Resolve conflicts
Continue rebase: git rebase --continue
Force push: git push --force-with-lease
Verify PR builds and tests pass
Prevention:
Keep PRs small (< 250 lines)
Merge PRs quickly once approved
Communicate about overlapping work
Best Practices
PR Size Guidelines
Ideal: < 250 lines of code changed
Maximum: < 500 lines of code changed
If larger, break into more issues
Review Process
For reviewers:
Review from bottom of stack upward
Each PR should be understandable independently
Approve PRs when ready (don't wait for entire stack)
For authors:
Keep each PR focused on one concern
Write clear PR descriptions
Update descriptions if implementation changes
Use "merge when ready" if available
Stack Maintenance During Review
Avoid force-pushing unless necessary
Update code in the relevant PR's branch
Changes to lower PRs may require rebasing upper PRs
Document blockers or dependencies in PR descriptions
Creates and maintains stacked PRs from a set of related Linear issues, respecting dependencies and blocked-by relationships. Use when the user mentions stacked PRs, working on related Linear issues in sequence, wants to tackle a parent issue with child issues using a stacked workflow, references Linear issue identifiers (like QUI-2982) with mentions of dependencies or blocked-by relationships, or needs to rebase/update an existing stack of PRs.
mcp__linear__get_issue
mcp__linear__list_issues
mcp__linear__list_comments
Bash
Read
Glob
Grep
AskUserQuestion
TodoWrite
EnterPlanMode
Stacked Linear PRs
Implements a workflow for tackling related Linear issues as stacked pull requests, where each issue becomes a PR that builds upon the previous one, respecting explicit dependencies.
Critical Rule: Always Fetch Before Rebasing
ALWAYS fetch the latest upstream before any rebase operation:
git fetch origin main
Failure to do this causes the most common stacked PR problem: including commits from an already-merged PR because your local main is stale.
Key Concepts
A stacked PR structure looks like:
main
βββ PR1: Feature flag (base)
βββ PR2: Device implementation β depends on PR1
β βββ PR3: Device tests β depends on PR2
βββ PR4: Mobile implementation β depends on PR1
βββ PR5: Mobile UI β depends on PR4
Workflow Overview
Progress Checklist:
- [ ] Step 1: Fetch and analyze issues
- [ ] Step 2: Build dependency graph
- [ ] Step 3: Determine work order
- [ ] Step 3.5: Decide planning approach (EnterPlanMode if needed)
- [ ] Step 4: Execute work plan (for each issue: branch, implement, commit, PR, verify checks)
- [ ] Step 5: Verify stack integrity
Step 1: Fetch and Analyze Issues
Fetch parent issue:
Use mcp__linear__get_issue with includeRelations: true to fetch the parent issue including blocked-by relationships.
Fetch child issues:
Use mcp__linear__list_issues with parentId filter to get all child issues.
Read issue comments:
For each issue, use mcp__linear__list_comments to fetch comments. Comments may contain additional context, clarifications, or dependencies not captured in the issue body.
Extract key information:
Issue ID and identifier (e.g., QUI-2982)
Title and description
Comments (important context and dependencies)
Branch name from branchName field
Blocked-by relationships from relations.blockedByIssues
Child issues
Step 2: Build Dependency Graph
Create a dependency map considering:
Explicit dependencies: blockedByIssues - if issue A is blocked by issue B, B must be completed first
Parent-child relationships: Children typically depend on parent (unless they block the parent)
Logical dependencies: Issues that reference each other in comments or descriptions
Use scripts/dependency_graph.py to visualize and validate the graph if needed.
Note: PRs are created as drafts by default to signal work-in-progress while building the stack. Mark as ready for review once the entire stack is complete or when individual PRs are ready.
PR body template:
## Summary
<Briefdescriptionofchanges>
## Related Issue
Addresses <issue-identifier> (<issue-url>)
## Stack Context
This PR is part of a stacked PR workflow:
- Base: <previous-pr-url or "main">
- Next: <next-pr-url or "none (top of stack)">
## Test Plan
<Testingapproach>
4e. Verify PR checks
Before moving to the next issue, ensure PR checks pass:
gh pr checks <pr-number> --watch
Important:
Wait for all CI/CD checks to complete and pass
If checks fail, fix issues before proceeding to next issue
Each layer of the stack should be solid before building on top
Failing checks in lower PRs will propagate issues to dependent PRs
If checks fail, address the issues, commit fixes, push, and wait for checks to pass again.
Step 5: Verify Stack Integrity
After all PRs are created:
Check that each PR (except the first) targets the previous PR's branch
Verify the PR chain is correct
List all PRs with their relationships
Provide the user with a summary and next steps
Important Notes
Branch naming:
Always use the branchName from Linear's issue data. If missing, generate using pattern: <team-key>-<issue-number>-<slug>
Merge strategy:
When a PR merges, remaining PRs need rebasing. After the bottom PR merges to main, update the next PR to target main. Continue this process up the stack.
Rebasing an Existing Stack
When PRs in a stack need to be updated (e.g., after a PR merges, or to incorporate main branch changes), follow this workflow carefully to avoid duplicate commits or merge conflicts.
Rebase Checklist
- [ ] Step R1: Fetch latest upstream and check merge status
- [ ] Step R2: Build the current stack state
- [ ] Step R3: Rebase in correct order (bottom to top)
- [ ] Step R4: Verify each PR after rebasing
- [ ] Step R5: Force push updated branches
Step R1: Fetch Latest Upstream and Check Merge Status
CRITICAL: Always fetch the latest main before any rebase operation:
git fetch origin main
Check which PRs in the stack have merged:
# For each PR in the stack
gh pr view <pr-number> --json state,mergedAt
If a PR has merged, its commits are now in main. Dependent PRs should be rebased onto main (not the old branch), and git will automatically skip the duplicate commits.
Step R2: Build the Current Stack State
List all PRs in the stack and their current base branches:
gh pr list --author <username> --state open --json number,title,headRefName,baseRefName
Identify:
Which PRs target main
Which PRs target other branches in the stack
Which base branches have been merged (their PRs should now target main)
Step R3: Rebase in Correct Order
Order matters! Always rebase from the bottom of the stack upward:
PRs targeting main first
Then PRs that depend on those
Continue up the stack
For a PR whose base has merged into main:
git checkout <branch-name>
git rebase origin/main
# Git will automatically skip commits already in main ("patch contents already upstream")
git push --force-with-lease
# Update PR base branch if needed
gh pr edit <pr-number> --base main
For a PR whose base has NOT merged:
git checkout <branch-name>
git rebase <base-branch-name>
git push --force-with-lease
Step R4: Verify Each PR After Rebasing
After rebasing each PR, verify it contains only the expected changes:
gh pr diff <pr-number> --name-only
Red flags to check for:
Files that belong to a different PR in the stack (indicates duplicate commits weren't skipped)
Unexpected files from other features
Missing expected files
If a PR contains unexpected files, the rebase was done against a stale base. Re-fetch and rebase again:
git fetch origin main
git rebase origin/main # or the correct base branch
Step R5: Force Push and Update PR Bases
After successful rebase:
git push --force-with-lease
If a PR's base branch has merged, update the PR to target main:
gh pr edit <pr-number> --base main
Common Rebase Issues
Issue: PR contains commits from another PR in the stack
Cause: Rebased onto a stale version of main that didn't include the merged PR.
Fix:
git fetch origin main
git rebase origin/main # Will skip duplicate commits
git push --force-with-lease
Issue: Merge conflicts during rebase
If conflicts occur:
Resolve conflicts in the affected files
git add <resolved-files>
git rebase --continue
If a commit was just for resolving previous rebase conflicts, consider git rebase --skip
Issue: "patch contents already upstream" messages
This is normal and expected! Git detected that a commit's changes are already in the base branch and skipped it. This happens when:
A dependent PR merged and its commits are now in main
Commits were cherry-picked between branches
Issue: PR base branch doesn't exist
Cause: Base PR was merged and branch was deleted.
Solution: The PR was automatically retargeted to main. Just rebase onto main:
git fetch origin main
git rebase origin/main
git push --force-with-lease
Checking Stack Health
Verify all PRs in your stack show only their own changes:
# Check each PR's files
gh pr diff 7868 --name-only # Should show only PR1 files
gh pr diff 7869 --name-only # Should show only PR2 files (not PR1)
gh pr diff 7870 --name-only # Should show only PR3 files (not PR1 or PR2)
If a downstream PR shows files from an upstream PR, it needs rebasing.
Automation Checklist
When asked to rebase a stack, follow this checklist:
git fetch origin main - Always first!
Identify which PRs in the stack are merged
List remaining PRs in dependency order
Rebase each PR onto its new base (main or parent branch)
Scenario: Parent issue with 3 child issues, no explicit dependencies, tackle in creation order.
Setup
Linear Issues:
QUI-2982: Implement user authentication (Parent)
QUI-2983: Add login form UI (Child)
QUI-2984: Implement JWT token service (Child)
QUI-2985: Add logout functionality (Child)
No blocked-by relationships, so default order is parent β children in creation order.
Execution
Step 1: Analyze issues
User: "Let's work on QUI-2982 and its child issues using stacked PRs"
Claude: I'll fetch QUI-2982 and analyze its child issues.
Step 2: Determine work order
Dependency Graph (Work Order):
1. QUI-2982 - Implement user authentication
2. QUI-2983 - Add login form UI
ββ Depends on: QUI-2982
3. QUI-2984 - Implement JWT token service
ββ Depends on: QUI-2982
4. QUI-2985 - Add logout functionality
ββ Depends on: QUI-2982
Step 3: Confirm with user
Claude: I've analyzed the issues. Here's the proposed work order:
1. QUI-2982 (Parent) - Implement user authentication
2. QUI-2983 (Child) - Add login form UI
3. QUI-2984 (Child) - Implement JWT token service
4. QUI-2985 (Child) - Add logout functionality
This will create a stack of 4 PRs. Shall I proceed?
Step 4: Execute (Issue 1)
# Checkout main and create branch for QUI-2982
git checkout main
git pull origin main
git checkout -b qui-2982-implement-user-authentication
# Work on the issue...# (Make changes, write tests, etc.)# Commit
git add .
git commit -m "feat: implement user authentication infrastructureAdd base authentication module and interfacesAddresses QUI-2982π€ Generated with Claude CodeCo-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>"# Push and create PR
git push -u origin qui-2982-implement-user-authentication
gh pr create \
--title "Implement user authentication" \
--body "$(cat <<'EOF'## SummaryAdds authentication infrastructure including user model and auth interfaces.## Related IssueAddresses QUI-2982 (https://linear.app/team/issue/QUI-2982)## Stack ContextThis PR is part of a stacked PR workflow:- **Stack position:** 1/4- **Base:** main- **Next in stack:** QUI-2983 (login form UI)## Stack Overview1. QUI-2982 - Implement user authentication (this PR)2. QUI-2983 - Add login form UI3. QUI-2984 - Implement JWT token service4. QUI-2985 - Add logout functionality## Changes- Added User model- Created AuthService interface- Added authentication middleware## Test Plan- Unit tests for User model- Integration tests for authentication flowEOF)" \
--base main
Add comment to Linear:
Use mcp__linear__create_comment:
{
"issueId": "<qui-2982-uuid>",
"body": "PR created: https://github.com/org/repo/pull/123\n\n"
}
Step 5: Execute (Issue 2)
# Create branch for QUI-2983 FROM current branch
git checkout -b qui-2983-add-login-form-ui
# Work on the issue...# Commit
git add .
git commit -m "feat: add login form UI componentCreate login form with validationAddresses QUI-2983π€ Generated with Claude CodeCo-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>"# Push and create PR targeting previous branch
git push -u origin qui-2983-add-login-form-ui
gh pr create \
--title "Add login form UI" \
--body "..." \
--base qui-2982-implement-user-authentication
# PR #123 merged to main# Update PR #124 to target main
gh pr edit 124 --base main
# Rebase QUI-2983 branch onto main
git checkout qui-2983-add-login-form-ui
git rebase main
git push --force-with-lease
Complex Dependency Graph
Scenario: Multiple issues with cross-dependencies and blocked-by relationships.
Setup
Linear Issues:
QUI-3000: Refactor database layer (Parent)
QUI-3001: Update User model schema
QUI-3002: Migrate existing data
Blocked by: QUI-3001
QUI-3003: Update API endpoints
Blocked by: QUI-3002
QUI-3004: Update frontend to use new API
Blocked by: QUI-3003
QUI-3005: Add new analytics queries
Blocked by: QUI-3001 (can work in parallel with migration)
1. QUI-3000 - Refactor database layer
2. QUI-3001 - Update User model schema
ββ Depends on: QUI-3000
3. QUI-3002 - Migrate existing data
ββ Depends on: QUI-3001
4. QUI-3003 - Update API endpoints
ββ Depends on: QUI-3002
5. QUI-3004 - Update frontend to use new API
ββ Depends on: QUI-3003
6. QUI-3005 - Add new analytics queries
ββ Depends on: QUI-3001
Note: QUI-3005 could be worked on in parallel with QUI-3002/3003/3004 since it only depends on QUI-3001.
Execution Strategy
Option 1: Strict sequential (simplest)
Work through all issues 1-6 in order, creating linear stack.
Option 2: Parallel branches (advanced)
After completing QUI-3001:
Claude: I found an existing branch for QUI-5001. Should I:
1. Use the existing branch and continue from there
2. Create a new branch (e.g., qui-5001-layout-v2)
3. Skip this issue
User: Use the existing branch
Step 3: Incorporate existing branch into stack
# Checkout and update existing branch
git checkout qui-5001-layout
git pull origin qui-5001-layout
# Verify it's up to date with main
git merge main
# Create PR if not exists
gh pr list | grep "qui-5001"|| gh pr create \
--title "Update layout components" \
--body "..." \
--base main
# Continue with next issue from this branch
git checkout -b qui-5002-add-new-widgets
# ... continue workflow
Result
PR for QUI-5001 updated to include stack metadata
New PRs for QUI-5002 and QUI-5003 created on top
Recovering from Conflicts
Scenario: A conflict occurs during rebase after bottom PR merges.
Setup
Stack:
PR #301: QUI-6001 β main (MERGED)
PR #302: QUI-6002 β main (rebase needed)
PR #303: QUI-6003 β qui-6002-branch (may need rebase after #302)
Problem
# After PR #301 merges
git checkout qui-6002-branch
git rebase main
# Conflict!
Auto-merging src/components/Button.tsx
CONFLICT (content): Merge conflict in src/components/Button.tsx
Resolution
Step 1: Resolve conflict
# View conflict
cat src/components/Button.tsx
# Resolve manually or with Claude's help# Edit the file to resolve conflicts# Mark as resolved
git add src/components/Button.tsx
# Continue rebase
git rebase --continue
Step 2: Verify changes
# Run tests
npm test# Build
npm run build
Step 3: Update PR
# Force push (safe with --force-with-lease)
git push --force-with-lease
# Update PR base
gh pr edit 302 --base main
Step 4: Cascade to next PR
# Rebase QUI-6003 onto updated QUI-6002
git checkout qui-6003-branch
git rebase qui-6002-branch
git push --force-with-lease
Prevention Tips
Keep PRs small (< 250 lines)
Merge PRs quickly once approved
Communicate with team about overlapping changes
Use feature flags for large changes
Partial Stack Execution
Scenario: User wants to work on only some issues from a set.
Setup
Linear Issues:
QUI-7000: Improve error handling (Parent)
QUI-7001: Add error tracking
QUI-7002: Improve error messages
QUI-7003: Add error recovery
QUI-7004: Update documentation
User only wants to work on 7001 and 7002 now, save 7003 and 7004 for later.
Execution
Step 1: Analyze all issues
Claude: I've found 4 child issues for QUI-7000. Here's the dependency order:
1. QUI-7000 - Improve error handling
2. QUI-7001 - Add error tracking
3. QUI-7002 - Improve error messages
4. QUI-7003 - Add error recovery
5. QUI-7004 - Update documentation
Would you like to work on all of these, or a subset?
User: Just 7000, 7001, and 7002 for now
Step 2: Execute partial stack
# Work on QUI-7000
git checkout main
git checkout -b qui-7000-improve-error-handling
# ... work, commit, create PR# Work on QUI-7001
git checkout -b qui-7001-add-error-tracking
# ... work, commit, create PR# Work on QUI-7002
git checkout -b qui-7002-improve-error-messages
# ... work, commit, create PR# Stop here (don't work on 7003 and 7004)
Step 3: Document for later
Claude: I've created PRs for QUI-7000, QUI-7001, and QUI-7002.
The remaining issues (QUI-7003 and QUI-7004) will depend on these PRs.
When you're ready to continue, you can either:
1. Run this skill again with QUI-7000 and specify issues 7003-7004
2. Manually create branches from qui-7002-improve-error-messages
Linear issues QUI-7003 and QUI-7004 have been noted with comments about the partial stack.
Result
Three PRs created and under review
Two issues remain for later work
Clear documentation of where to continue
Advanced Tips
Visualizing Complex Graphs
Use the dependency_graph.py script with Mermaid output for visual diagrams: