← ClaudeAtlas

deploy-drift-checklisted

Prove what is actually running in production matches the commit you think shipped, by fetching real bytes from the live site rather than trusting the deploy dashboard. Use when the user says a fix "should be live", asks why a change is not showing up, is about to debug production, or before writing any postmortem.
sriptcollector/toolbay-skills-claude-code-skill-pack · ★ 0 · Code & Development · score 72
Install: claude install-skill sriptcollector/toolbay-skills-claude-code-skill-pack
# Deploy Drift Check ## Install Save this file as `~/.claude/skills/deploy-drift-check/SKILL.md`, or `.claude/skills/deploy-drift-check/SKILL.md` to scope it to one repo. Claude Code auto-discovers it. Invoke with `/deploy-drift-check` or by asking "is my latest commit actually live?". ## Why this exists The most expensive class of debugging is investigating code that was never running. Someone reports a bug you fixed last week, you read the fix, the fix is correct, and you spend two hours on a theory that cannot be true because production is serving a build from before it. Dashboards lie by omission here. A deploy marked "Ready" tells you a build succeeded, not that it contains the commit in your working tree. Repos with no git remote, manual deploy steps, protected branches, failed CI, or a promote step someone forgot all produce a green dashboard and stale bytes. **Never diagnose production until you have proven what production is running.** ## Step 1 — Establish what SHOULD be live ``` git log --oneline -5 git status --short git rev-parse HEAD ``` Note the HEAD hash and whether the tree is dirty. Uncommitted work is not deployed anywhere, and it is a common source of "but I fixed that". Then check whether the commit even left the machine: ``` git remote -v git log origin/HEAD..HEAD --oneline 2>/dev/null ``` Two failure modes, both common: - **No remote at all.** Nothing auto-deploys, and the code exists only here. Say so plainly; it is also a backup problem