Land And Deploy

What Is This?

Overview

Land and Deploy is a workflow automation skill designed to handle the final stages of shipping code to production. It picks up where the pull request creation step leaves off, managing the merge process, monitoring continuous integration pipelines, waiting for deployment completion, and verifying that production systems are healthy through canary checks. This skill is part of a broader development workflow chain that treats the path from code review to live production as a structured, observable process rather than a manual sequence of steps.

The skill operates by merging an approved pull request, then actively monitoring the CI/CD pipeline until the deployment reaches production. Once deployed, it runs canary health checks to confirm that the new code is behaving correctly in the live environment. If issues are detected during verification, the workflow surfaces them immediately so engineers can respond before problems escalate.

This tool is built for teams that want consistent, repeatable deployment behavior without relying on engineers to manually track each stage of the pipeline. By automating the handoff between merge, deploy, and verify, it reduces the cognitive overhead of shipping and lowers the risk of human error during a critical phase of the development cycle.

Who Should Use This

• Backend and full-stack engineers who regularly ship features and need a reliable way to confirm production health after each deployment
• DevOps and platform engineers who want to standardize the merge-to-production workflow across multiple teams or repositories
• Engineering leads who need confidence that every deployment includes a verification step before the team moves on
• Developers working in fast-moving codebases where multiple pull requests land per day and manual tracking becomes impractical
• Teams using trunk-based development or continuous delivery practices where speed and reliability must coexist

Why Use It?

Problems It Solves

• Manual deployment tracking is error-prone. Engineers often merge a PR and assume the deployment succeeded without verifying production health, leading to silent failures that surface later.
• Context switching during deployments is costly. Watching CI logs, checking deployment dashboards, and running health checks across separate tools breaks focus and wastes time.
• Inconsistent verification practices create risk. Without a standard post-deploy check, some deployments get verified thoroughly while others ship without any confirmation.
• Delayed detection of production issues increases incident severity. The longer a bad deployment goes undetected, the more users are affected and the harder the rollback becomes.

Core Highlights

• Merges pull requests and immediately begins monitoring the CI pipeline
• Waits for deployment completion before proceeding to verification
• Runs canary checks against production to confirm system health
• Integrates with the broader ship workflow, taking over after PR creation
• Supports natural language triggers such as "merge", "land it", and "ship it to production"
• Uses Bash, Read, Write, and Glob tools for flexible pipeline interaction
• Surfaces failures at each stage so engineers can intervene with full context

How to Use It?

Basic Usage

Trigger the skill after a pull request has been created and approved. The skill accepts natural language commands and maps them to the workflow automatically.

merge
land it
deploy
ship it to production
merge and verify

The skill will locate the open pull request, execute the merge, and begin polling the CI system for status updates.

Specific Scenarios

Scenario 1: Merging after code review approval

A pull request has been reviewed and approved. Instead of manually clicking merge and then watching the pipeline, you issue the command and the skill handles the rest, reporting back when production is verified.

## The skill executes steps equivalent to:
gh pr merge --squash --auto
## Then polls CI status
gh run watch
## Then checks production health endpoint
curl -f https://your-app.com/health

Scenario 2: Catching a failed canary check

The deployment completes but the canary check returns a non-200 response. The skill reports the failure immediately, giving the engineer the information needed to decide whether to roll back or investigate further.

Real-World Examples

• A feature branch is approved on Friday afternoon. The engineer runs the land command, confirms production is healthy within minutes, and closes the laptop with confidence.
• A platform team enforces that all repositories use this skill as the standard merge path, ensuring every deployment includes a health verification step regardless of who is shipping.

Important Notes

Requirements

• An approved pull request must exist before the skill can execute the merge step
• The repository must have a configured CI/CD pipeline that the skill can monitor
• A production health endpoint or canary check target must be accessible for verification