huntiehuntie/skills/land-stack/SKILL.md

land-stack

Skill0 starsChanged 21 days agoMITView on GitHub

Land a stack of approved GitHub pull requests by squash-merging them one at a time, bottom first, so each PR becomes its own commit on the base branch. Takes the top PR number or a GitHub stack number. Use only when the user invokes /land-stack.

2 other projects use a version of this.

Adopted by

Most recently taken up by

amrtawfik160/bb-orchestration-skillstheir own version, first seen Oct 13, 2026
Neko-Catpital-Labs/Invokertheir own version, first seen Mar 23, 2026

Other versions2 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 2
Neko-Catpital-Labs/Invoker★ 20same name
amrtawfik160/bb-orchestration-skills★ 1same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository12 other files it gives its agents.
- autopilotSkill
- commit-msgSkill
- handoffSkill
- planSkill
- principle-minimal-commentsSkill
- recallSkill
- reflectSkill
- review-3p-skillSkill
- submitSkill
- submit-stackSkill
- test-planSkill
- trace-flowSkill

The file

We split this skill into the rules it gives an agent

3 rules. About 0 are common, 1 is distinctive, and 2 are very specific to this project.

≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.

Common
Distinctive
Very specific

Very specific:
Before the next layer, wait a few seconds for GitHub to retarget it, then confirm its base is the trunk and its files are only its own.
line 26
Distinctive:
Stop at the first failure and report what merged and what did not.
line 28
Very specific:
Update the plan that names the branch: its Status: tag becomes [merged #<bottom>], or the per-PR numbers when there are several.
line 33

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.

Files

SKILL.md

Land stack

Merges a stack PR by PR, never with GitHub's "Squash and merge stack" button, which folds every layer into one operation. Each layer lands as its own squash commit, and the next layer is checked before it merges.

Merging is outward-facing and cannot be undone, so this runs only on the user's explicit request, for the stack they named.

Before merging

List the stack bottom to top: gh stack view --json when the stack is checked out, else read each PR's baseRefName from gh pr view <n> --json number,title,baseRefName,mergeable,mergeStateStatus,reviewDecision,isDraft and follow the bases down to the trunk.
Find the ready layers: walk up from the bottom and stop at the first layer that is a draft, not MERGEABLE, or has a reviewDecision other than APPROVED. Every layer below it lands; it and every layer above stay open, even ones that are ready, since a layer cannot land before the one under it. UNSTABLE alone is fine: it means a non-required check is pending or failing, and branch protection decides at merge time. When the bottom layer is not ready, stop and report.
Tell the user in one line the PRs that will land, in order, and the first one that stays and why, then start; do not ask again.

Merging

For each ready layer, bottom first:

gh stack merge <pr> --yes --squash merges that PR alone, since it is the bottom of what remains. In a repository with no GitHub stack, gh pr merge <pr> --squash does the same. Use the merge method the user named, if any.
Confirm it: gh pr view <pr> --json state,mergeCommit reads MERGED, and note the merge commit.
Before the next layer, wait a few seconds for GitHub to retarget it, then confirm its base is the trunk and its files are only its own. A layer that still carries the merged layer's changes, or shows CONFLICTING, stops the run.

Stop at the first failure and report what merged and what did not. Never bypass branch protection, and never fall back to merging the remaining layers together.

After

Report each PR with its merge commit, bottom to top, then the layers left open and what each is waiting on. The lowest of them now targets the trunk.
Update the plan that names the branch: its Status: tag becomes [merged #<bottom>], or the per-PR numbers when there are several.
In the checkout, scripts/pull to bring the trunk level. The local stack's commits are now on the trunk as squash commits; leave the task branch for the user to delete.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

Reviews can't be read right now.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free