← ClaudeAtlas

craft-pr-stacklisted

Opening a pull request on top of one that has not merged. When a stack earns its merge order, how to rebase a child, and where the child lands when the parent merges.
attac-t/the-foundry · ★ 1 · AI & Automation · score 57
Install: claude install-skill attac-t/the-foundry
# Skill: Craft PR Stack > "A stack is a merge order. Impose one only where the work already has one." ## When | Stack | Branch from `main` | |---|---| | The second change needs the first | Neither needs the other | | Both edit a file every change edits — manifest, lockfile, changelog | They touch different files | On that second row a green gate is not evidence: each branch passes alone while the merge of both is wrong. A stack imposes a merge order, and an order nobody needs is one somebody has to wait for. ## The Protocol Branch from the open PR you depend on, and target it. Do not branch from `main` and wait. ```bash gh pr create --base <parent-branch> ``` When the parent moves, replay the child's own commits onto it: ```bash git rebase --onto <parent-branch> <old-parent-tip> <child-branch> git push --force-with-lease origin <child-branch> ``` Once the parent is rewritten, nothing computes `<old-parent-tip>`. Read it from the reflog: `git rev-parse <parent-branch>@{1}`, or `origin/<parent-branch>@{1}` if someone else force-pushed. ## The Landing Everything above is git and holds anywhere. This section is one forge's behaviour, and the commands are `gh`. Confirm it on any other before relying on it. **Merging a parent does not move its children.** The base branch survives the merge, the child stays aimed at it, and merging the child lands the work on a stale branch instead of the trunk. **Deleting the base does not move them either — it closes them.** Seen in