Drift

Analyze the current session for scope drift. Compare all work done against the original goal.

Important

• This skill reads the current conversation context and git state — no arguments needed
• Be honest. If the user drifted, say so clearly. If they're on track, confirm it quickly
• Tangential work isn't always bad — adjacent improvements that support the goal are fine. Flag only work that genuinely doesn't serve the original objective
• Do not judge the quality of changes — only their relevance to the stated goal

Instructions

Step 1: Identify the original goal

Read the conversation from the beginning. Find the first substantive request — this is the stated goal. Capture it as a single sentence.

If there were multiple explicit goal changes (user said "actually, let's do X instead"), use the most recent explicit goal.

Step 2: Catalog all changes

List every action taken in this session:

• Files read (exploration)
• Files created or modified (implementation)
• Commands run (tests, builds, deploys)
• Skills invoked
• Plans created or modified

Also check git diff and git status for the concrete file-level changes.

Step 3: Classify each change

For each change, classify as:

• ON-GOAL — Directly serves the stated objective
• ADJACENT — Supports the goal indirectly (e.g., fixing a test that blocks the feature, updating a dependency needed for the change)
• TANGENTIAL — Unrelated improvement noticed while working (e.g., refactoring nearby code, fixing an unrelated bug, adding unrelated tests)
• DRIFT — Actively diverges from the goal (e.g., starting a different feature, major refactor of unrelated module)

Step 4: Assess completion

Evaluate whether the original goal is:

• COMPLETE — All aspects of the original request are done
• PARTIAL — Some parts done, some remaining
• NOT STARTED — Exploration happened but implementation hasn't begun
• BLOCKED — Can't proceed without resolving something

If partial, list what's remaining.

Step 5: Output report

DRIFT CHECK — [session duration if available]

GOAL: [1-sentence original goal]

STATUS: [COMPLETE | PARTIAL (X%) | NOT STARTED | BLOCKED]

CHANGES:
  ON-GOAL:
    * [file/action] — [what it does for the goal]
    ...

  ADJACENT:
    * [file/action] — [how it supports the goal]
    ...

  TANGENTIAL:
    * [file/action] — [what it does, why it's not on-goal]
    ...

  DRIFT:
    * [file/action] — [how this diverges]
    ...

VERDICT: [ON TRACK | MILD DRIFT | SIGNIFICANT DRIFT | OFF COURSE]

[If drifted]: REMAINING TO FINISH ORIGINAL GOAL:
  1. [specific task]
  2. [specific task]
  ...

Step 6: Suggest next action

Based on the verdict:

• ON TRACK: "You're focused. Keep going." (no further output needed)
• MILD DRIFT: "Minor tangential work detected. Original goal is [X%] done. Suggest finishing [remaining items] before continuing tangential work."
• SIGNIFICANT DRIFT: "You've spent significant time on [tangential area]. Original goal is [X%] done. Recommend returning to: [next step for original goal]."
• OFF COURSE: "The original goal ([goal]) appears abandoned. [N] files changed, none serving it. Want to: (A) return to original goal, (B) redefine goal to match current work, (C) acknowledge the pivot and continue?"

Error Handling

1. No clear goal found: "I can't identify a clear original goal from this session. What were you trying to accomplish? I'll track from here."
2. Very short session (< 3 messages): "Too early to assess drift. Check back after more work is done."
3. Multiple explicit goal changes: Use the most recent. Note: "Goal changed mid-session from [old] to [new]. Assessing against current goal."

Examples

Example 1: Mild drift

Session: User asked to "add input validation to /users/register". Claude added validation, then also refactored the error handling in a nearby endpoint. Output: MILD DRIFT — Goal 100% complete. Tangential: error handling refactor in /users/update. "Original goal is done. The refactor is adjacent work — fine to continue or commit what you have."

Example 2: Significant drift

Session: User asked to "fix the auth token expiry bug". Claude read auth code, fixed the bug, then started migrating the entire logging system to Winston. Output: SIGNIFICANT DRIFT — Goal 100% complete but session continued into unrelated logging migration (34 files). "Auth fix is done and should be committed separately. The Winston migration is a separate task — consider starting a new branch."

Example 3: On track

Session: User asked to "implement rate limiting for auth endpoints". Claude explored codebase, proposed approaches, user picked one, implementation in progress. Output: ON TRACK — Goal ~60% done. All work serves the objective. "Keep going. Remaining: write tests, add config for limits."