Did Your Coding Agent Drift?

How to use it — best practices

Six steps. The whole thing fits around how you already work — you write a plan, you build, you check, and you keep the record current as the project grows.

1. 1

   Write a detailed plan with your coding agent.

   As detailed or as rough as you like. This is the plan you were going to write anyway — nothing about it has to change to work with this skill.

2. 2

   Before your agent starts building, run init.

   This is the thirty seconds that makes everything after it easy. Init turns your draft plan into the single baseline document every future check measures against, and asks you to type one sentence — in your own words — saying what "done" means. That sentence lands in its own commit with your name and the date, so months later anyone can prove the goal was yours and not something an agent wrote for you.

   /did-we-drift init

   Init also builds your dashboard: a visual page listing every phase, wave, and to-do in your plan, so you can see the whole run laid out before a line of it is built.

3. 3

   After a coding session, run the check.

   At a checkpoint, at the end of a phase, before a context handoff, or when you pick the project back up after time away. Your agent reads what it actually committed and compares it against the baseline.

   /did-we-drift

   If you forgot to run init

   Forgot to run init at the start? That's fine. Your agent will dig through the context and do its best to reconstruct what you originally intended — a dated note, a message, a line in a README — then show you what it found and ask you to confirm it. Running init is better. It isn't required.

4. 4

   Read the verdict.

   You get one word — on track, drifted, inconclusive, or blocked — plus the specific commits and file lines behind it, and if something went sideways, the smallest fix that puts it right. Your dashboard updates at the same time, so the visual view never lags the verdict.

5. 5

   Ask for the dashboard whenever you want to see where things stand.

   This isn't a re-render of an old page. Your agent goes and checks first: it runs the full audit, re-derives every step's status against your plan, re-runs the evidence it can actually run, updates the page, and then opens it. So you get today's answer, not last week's.

   /did-we-drift dashboard

6. 6

   At a milestone or release, run update.

   Old plan files rot: a note that says "fix before stage 10" is still sitting there when stage 10 starts. Update checks the work first and refuses to refresh over unresolved drift, then adds a new dated entry to the facts and walks every open note and waiting-on-you item to a recorded outcome — resolved, carried, or escalated. Nothing dies quietly in a hand-off.

   /did-we-drift update

You're done when the check prints ON TRACK · Baseline: RATIFIED and your dashboard opens showing what you planned beside what got built.

Why drift is so hard to see

• →Agents optimize the next step, not the destination — every detour is locally rational.
• →Plans multiply instead of updating. Each session writes its own tracker or handoff note, and the truth forks.
• →“Done” gets claimed without runnable evidence, then inherited as fact by the next session.
• →Goalposts move silently. A plan file edited mid-sprint makes every later commit look on-plan forever.

A point-in-time code review catches none of this. A drift audit catches all of it.

What it actually does

Did We Drift is instructions, not software — a skill your Claude reads and follows. Nine plain-text files and one small checker script. No daemons, no accounts, no telemetry. Here's the system:

1. 1.

   It finds what you actually declared you wanted.

   Bounded searches — never a full repo read — locate your planning documents, including ones hiding in .gitignore. Those get flagged, because a future session cloning the repo never sees them.

2. 2.

   It never invents the goal from your code.

   “The code does X, so X must have been the plan” would legitimize every drift ever committed. So the skill quotes and cites instead. When it needs you to choose, it offers up to three candidates pulled from things you actually said — each with its date, its source, and an explicit line saying what that choice would exclude. If nothing you declared survives, the honest answer is INCONCLUSIVE, not a guess.

3. 3.

   It grades two things separately, and never confuses them.

   The work: is the build going where you asked? The basis: how solid is the thing we measured against? A project with real intent scattered across a few documents gets graded on its work AND told its planning is scattered. It is never told it has no plan.

   “A messy plan document is never graded as drift — that's reported on the basis axis, so one problem never gets counted twice.”

4. 4.

   It checks who actually wrote your plan.

   Nearly every long autonomous run starts with “write me the plan and keep working until it's done.” The agent writes something impeccable — dated, specific, even saying “do not invent new scope” — and no human ever authored the goal it enforces. Every candidate goal is classified on mechanical git evidence, so that gets caught and reported instead of read back to you as your own intent.

5. 5.

   It actually runs the “done” claims.

   Completion claims are sampled adversarially — the highest-impact finished task, the most recent one marked done, one area you said to stay out of — and run for real. What can't be run is reported UNVERIFIABLE rather than quietly passed. Routine maintenance and dependency bumps are classified as such, so merges don't trigger false alarms.

6. 6.

   It refuses to certify more than it checked.

   If your plan names a goal but no enumerable list of sanctioned work, the skill says so and will not declare “on track.” Finding no drift when there was nothing to compare against isn't a clean bill of health — it's an unfinished audit, and it gets labeled one.

See where it really stands: the dashboard

Your cockpit redesign is 43% built
Three of seven steps are done. One is being worked on now.
████████████░░░░░░░░░░░░░░  43% built — 3 of 7 steps finished

WHAT WE PLANNED                    WHAT WE BUILT
Make your approve-or-deny          ✓ Built
answers actually reach your        When:  Aug 4 → Aug 6 · took 2 days
assistant. Before this, you        How it went: Three review rounds.
could tap Approve and nothing      Two bugs found and fixed.
would happen.                      Proof: Shipped in beta.17
▸ Want the technical specs?

• →A completion meter that can't lie — the percentage is computed from the row statuses at render time, so there's no number to set by hand and it can never disagree with the list beneath it.
• →Nothing is marked done on momentum. A ticked box whose evidence doesn't hold up shows as In progress with the reason, not as Built.
• →Missing facts say “not recorded” instead of vanishing, so a thin record never passes for a clean one.
• →What changed since you last looked, and what's waiting on you — the dated decisions blocking the build, written as the question you have to answer.
• →A bad verdict looks bad. “Off course” is never rendered in the same calm tone as “on track” — and colour never carries meaning alone.

It is a view, never a second authority. It makes no claim your plan doesn't already make, and if the two ever disagree, the plan wins and the page gets corrected. When the audit finds no admissible plan, the meter is hidden rather than recoloured — a percentage computed against a plan that was just ruled inadmissible is a lie, however pretty.

Built in public — and tested against its own failures

Who it's for

Frequently asked questions