---
name: deploy-drift-check
description: 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.
---

# 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](https://toolbay.ai/product/deploy-drift-check). Free to use, modify, and share.
Keep this line and others can find it too.