land-and-deploy
FeaturedMerge PR, wait for CI, verify deploy, run canary. The complete landing pipeline.
Install
Quality Score: 96/100
Skill Content
Details
- Author
- FlorianBruniaux
- Repository
- FlorianBruniaux/claude-code-ultimate-guide
- Created
- 8 months ago
- Last Updated
- yesterday
- Language
- Python
- License
- CC-BY-SA-4.0
Integrates with
Similar Skills
Semantically similar based on skill content — not just same category
land
Post-merge landing: take merged MR(s) to verified-in-production by executing the project's landing runbook — watch the main pipeline(s) to green, apply or hand off migrations, deploy in the runbook's order, then canary-verify (health checks, smoke checks) before declaring shipped. Runbook-driven: reads docs/landing.md; on first run it drafts one by inspecting the repo (CI config, migrations, health endpoints) and confirms it with you. Every step is tagged [agent] (executed directly) or [human] (prod-locked — handed to you as exact commands and waited on, never assumed). Hard stops: red pipeline, failed migration, failed canary, unconfirmed human step. Never auto-rolls-back; prepares the revert and asks. Use when: "land this", "deploy the merge", after /ship-feature merges, "take it to prod", running post-merge follow-ups (migrations, deploy order, canary).
land
Take a committed branch from local to merged — push it, confirm which GitHub account each tool actually acts as in this repo, open the PR through the one that matches (github-mcp where loaded, gh where its login is confirmed), then fast-forward main and check CI. Use when asked to land, ship or publish a branch, open a pull request, merge to main, or get a branch in; the step after /commit. Use it even when the request already names the mechanism — 'squash these and merge', 'just merge it into main', 'force push it' — a named mechanism is the case these guards exist for, not a reason to skip them. Guards two silent failures: gh and github-mcp can authenticate as different accounts, so a PR lands under the wrong identity with no error, and integration is a local --ff-only merge because a squash would collapse the logical split /commit just made. Stops for confirmation before pushing main. To make the commits first use commit; to review before landing, code-review.
shipit
Land a reviewed pull request: discover the open PR for the current branch, push any unpushed commits, wait for CI to go green, then squash-merge it so the PR title (which may carry a version) lands as the commit subject. Handles a PR that has fallen behind its base (rebase + force-with-lease) and surfaces branch-protection rejections verbatim. Project-agnostic — it knows nothing about how any project versions itself. Invoke ONLY on explicit ship intent — the user says "ship it", "land the PR", "land this", or runs "/shipit". Landing merges, which is irreversible: never infer ship intent from a PR merely being approved, green, or finished.