← ClaudeAtlas

deploy-and-provelisted

Use when the user asks to deploy, publish, release, promote, or confirm that the latest version is live, especially when success must be proven from the production provider and real runtime rather than local state.
YosefHayim/dufflebag · ★ 2 · AI & Automation · score 68
Install: claude install-skill YosefHayim/dufflebag
# 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 versio