land-and-deploy (gstack)
- Release
Takes an approved change the rest of the way — merges it and pushes it live to production. Its job is the deploy itself, distinct from preparing the change and opening a PR, from watching how the release behaves afterward, and from guarding against destructive commands.
A situation it fits
Everything is reviewed and you just want to get this into production now — merge it and deploy it to users.
3 scenarios in the bank answer to land-and-deploy (gstack). The rest are in the game.
Skills it gets confused with
These share a family with land-and-deploy (gstack), which is another way of saying they are the ones you might reach for by mistake.
- canary (gstack)Watches a release right after it goes out, comparing the new version's health signals against the old so a bad deploy is caught early and can be rolled back. It monitors AFTER the deploy, unlike preparing the change, performing the deploy, or intercepting risky commands.
- careful (gstack)Acts as a safety net around destructive shell commands — force-pushes, recursive deletes, dropping a table — pausing to confirm before something irreversible runs. It guards individual dangerous actions, not the steps of preparing, deploying, or monitoring a release.
- ship (gstack)Runs the pre-merge release pipeline on a finished change — merges the base branch, runs the tests, reviews the diff, bumps the version and changelog, then commits and opens the pull request. It gets a change ready to land and raises the PR; it is not the act of deploying to production, watching a deploy, or blocking a dangerous command.
Knowing what land-and-deploy (gstack) does is the easy half. Telling it apart from the others under time pressure is the game.
Today's sessionland-and-deploy (gstack) is part of garrytan/gstack. Licence: MIT. The description above was written for this game, not taken from the skill.