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, not just a deploy problem.
• Unpushed commits. They are not live no matter what the dashboard says.

Step 2 — Pick a witness

A witness is something whose bytes CHANGED in the commit you care about and that you can fetch from the live site without authenticating. Ranked by reliability:

1. A generated text route: robots.txt, sitemap.xml, a public JSON endpoint. Best witness, because it is generated at request time from source.
2. A string in server-rendered HTML: a heading, button label, meta description.
3. A hashed asset filename in the HTML.
4. A version endpoint, if one exists.

Do not use anything behind a CDN cache you cannot bust, anything requiring a login, or an image. You will be testing the cache, not the deploy.

If the commit changed no observable output, say so and stop. You cannot verify a pure refactor from outside, and pretending otherwise is worse than admitting it.

Step 3 — Fetch the live bytes and compare

curl -s https://<host>/robots.txt

Compare against what the source in your working tree would produce. Read the source that generates it and reason about the expected output rather than guessing.

Then state one of exactly three verdicts:

• LIVE — the witness matches HEAD. Production is current. Proceed with the real investigation.
• DRIFTED — the witness matches an older commit. Stop all debugging. Find which commit is live (Step 4), then deploy before anything else.
• UNPROVEN — no usable witness. Say this explicitly. Do not round it up to LIVE because everything "looked fine".

Step 4 — When drifted, find out how far back

Identify the deployed commit before redeploying, because the gap is the story:

• Provider CLI or API, if there is one (vercel ls, flyctl releases, gh api repos/{owner}/{repo}/deployments).
• Bisect by witness: pick strings introduced by different commits and test which are present.

Then report: which commit is live, which is HEAD, how many commits and how many days sit between them, and which user-visible changes were in that gap. "Three weeks and 18 commits behind, including the checkout fix" is actionable. "Out of date" is not.

Step 5 — Report

Keep it to five lines:

HEAD:      <hash> <subject>            (<n> unpushed)
Deployed:  <hash or "unknown">
Drift:     <n commits / n days>  or  NONE
Witness:   <what you fetched, and what it showed>
Verdict:   LIVE | DRIFTED | UNPROVEN

If DRIFTED, add one line naming the most important user-visible change that is not live. That line is what makes someone act.

Rules

• Verify before diagnosing, always. This check costs 30 seconds; the alternative costs hours.
• A 200 response is not proof of anything. Error pages, maintenance pages, and stale caches all return 200 happily.
• Never say "should be live". Either you fetched bytes that prove it or you report UNPROVEN.
• Re-run this after deploying. A deploy that silently failed looks exactly like a deploy that worked until you check.

From Toolbay. Free to use, modify, and share. Keep this line and others can find it too.