# Deploy And Prove

> Use when the user asks to deploy, redeploy/redploy, publish a worker/site/service, multi-site or multi-domain deploy, cf:deploy / wrangler deploy, or prove production/live (curl smoke, webhook, e2e production ready, "is it live"). Especially when success must be proven from the production provider and real runtime rather than local state. Do not use for "do not deploy / run local only", or for "promote" meaning lift types/schemas into a shared package.

- Skill: `yosefhayim/deploy-and-prove` (Agent Skill)
- Install (CLI): `npx skillmds@latest add yosefhayim/deploy-and-prove`
- Raw SKILL.md: https://api.skillmd.com/api/skills/yosefhayim/deploy-and-prove/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- Author: YosefHayim (https://skillmd.com/u/yosefhayim)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/yosefhayim/deploy-and-prove

---


# Deploy and Prove

Deployment has two identities: the intended source and the artifact actually serving users. Prove both, plus behavior, before calling a release live.

## Safety

- Confirm the deployment target, environment, provider, branch/tag policy, and user authorization before causing external state changes.
- Inspect current production state and release instructions first. Do not infer a version bump, create a tag, publish a package, migrate data, or promote to production when the request does not authorize it.
- Never expose provider tokens, environment values, customer data, or private logs. Use safe smoke inputs and read-only provider checks where possible.
- Preserve rollback capability. Stop on unclear database compatibility, destructive migrations, failed health gates, or a source/version mismatch.

## Workflow

1. Define “latest”: local HEAD, remote branch SHA, release tag, package version, image digest, deployment ID, or another immutable identity. Reconcile differences before deploying.
2. Read repository release docs and inspect branch cleanliness, upstream state, version, changelog, migration requirements, build inputs, and existing production identity.
3. Run narrow checks and the full repository verification gate from the exact source to deploy. Build the release artifact and record its digest, provenance, or package contents when supported.
4. Use the documented provider-native deployment path. Capture deployment/run ID, source SHA/tag, artifact version/digest, target environment, and timestamps.
5. Monitor the provider to a terminal state. Inspect build/runtime logs and health signals; a CLI command returning zero before rollout finishes is not success.
6. Read production back from an independent surface: provider API/dashboard, package registry, image registry, deployment metadata, or response headers/version endpoint.
7. Exercise a harmless real production smoke path that covers the changed behavior. For packages, perform a fresh isolated install and run the affected command; for web/API, use the public origin rather than a local server.
8. Compare intended and served identities. If they differ or behavior fails, stop the claim, preserve evidence, and follow the documented rollback or recovery path within authorization.

## Verification

Report:

- intended source SHA, tag/version, and clean/dirty state;
- fresh verification and artifact build results;
- provider deployment/run ID and terminal status;
- registry, provider, or live-runtime identity readback;
- smoke-test command or flow and observed behavior;
- logs/health issues, propagation caveats, and rollback readiness;
- exact production URL or package coordinate when safe.

Do not equate a pushed commit, merged PR, created tag, successful build, registry metadata, or provider “started” state with a proven live deployment.