deploy-verify

Overview

Release engineer workflow that verifies a deployment after merge. Runs canary checks on the live site and triggers revert if critical failures are detected.

How this differs from other skills:

• /ship-milestone — end-to-end shipping (build → test → commit → push). This skill runs AFTER merge/deploy.
• /code-review — pre-merge review. This skill is post-merge verification.
• /runbook — incident response. This skill is proactive verification to prevent incidents.

Step 1: Determine Target

Parse arguments to identify what to verify:

• URL provided: Use directly as the canary target
• PR provided: gh pr view <number> --json mergedAt,headRefName,baseRefName to confirm merge, then determine deploy URL
• Neither: Check for deploy URL in config:
  • .env or .env.production → DEPLOY_URL, PRODUCTION_URL, BASE_URL
  • vercel.json → project URL
  • wrangler.jsonc → workers URL

If no URL can be determined, ask the user.

Step 2: Wait for Deploy

If a PR was just merged, the deploy may be in progress:

# GitHub Actions: check deploy workflow status
gh run list --branch main --limit 5 --json status,conclusion,name,createdAt

# Wait for running deploy (poll every 30s, max 10 min)
gh run watch $(gh run list --branch main --limit 1 --json databaseId -q '.[0].databaseId') --exit-status

If no CI deploy is detected, assume the deployment is already live.

Step 3: Canary Checks

Run these checks against the target URL. Each check produces a pass/fail result.

Check 1: Page Load (Critical)

# HTTP status check
HTTP_STATUS=$(curl -s -o /dev/null -w "%{http_code}" "$URL" --max-time 10)
# Should be 200

# Response time
RESPONSE_TIME=$(curl -s -o /dev/null -w "%{time_total}" "$URL" --max-time 10)
# Should be < 3.0 seconds

Pass: HTTP 200 AND response time < 3s Fail: Non-200 status OR response time > 5s Warn: Response time 3-5s

Check 2: Key Content Verification

Verify critical content is present on the page: