Scope Sentinel

Monitors your working session and detects when you've drifted from your stated task into unrelated changes. The coding equivalent of a GPS "recalculating" —...

Security Scan

The instructions match the stated purpose (detecting scope drift in a coding session); it requires access to your repository and will likely run or propose git operations, but it does not request unrelated credentials or install arbitrary code.

Purpose & Capability

Name and description (detecting drift from a stated coding task) align with the SKILL.md: it describes anchoring a task, monitoring file edits, classifying changes, and offering stash/commit/expand/continue choices. None of the declared requirements (there are none) contradict the stated purpose.

Instruction Scope

SKILL.md describes monitoring file modifications, reading branch names and commit messages, classifying changed files, tracking time, and offering git-style actions (stash/commit). These actions are coherent with the goal but are described at a high level — the agent will need to read the repository, inspect diffs, and may propose or perform git operations. Because the instructions are open-ended (e.g., 'classify: does this change relate to the stated task?'), an agent could read many files and make repository mutations unless constrained.

Install Mechanism

Instruction-only skill with no install spec and no code files — nothing will be downloaded or written by a provided installer. This is low-risk from an install perspective.

Credentials

The skill requests no environment variables or credentials, which is appropriate. However, to function it implicitly requires read (and possibly write) access to the project working tree and git metadata (branch name, commit messages, diffs). That implicit need is proportional but should be understood: the skill will need filesystem/git permissions to monitor and to carry out actions like stash/commit.

Persistence & Privilege

The skill is not always-enabled and does not request persistent privileges or to modify other skills. The SKILL.md contemplates writing session logs and committing/stashing changes in the repository, which are normal privileges for a repo tool and are scoped to the repository rather than system-wide settings.

Assessment

This skill is internally consistent with its purpose, but before enabling it consider: (1) it needs access to your project files and git metadata — expect it to read diffs and branch names; (2) it may propose or perform repo actions (stash, commit, create separate commits) — restrict it to ask for confirmation or run in read-only mode if you don't want automatic mutations; (3) because the SKILL.md is high-level and leaves classification heuristics to the agent, results can be subjective and produce false positives; (4) if you're cautious, try it on a disposable branch or clone, or disable autonomous invocation so you review its suggested actions before they run.

"The most expensive line of code is the one you didn't need to write. The most expensive refactor is the one you started 'while you were in there.'"

What It Does

You sit down to fix a bug in the checkout flow. Two hours later you've reformatted the auth module, added types to three utility files, renamed a database column, and upgraded a dependency. The bug? Still there.

Scope Sentinel watches what you're actually doing and compares it to what you said you'd do. When the delta grows too large, it intervenes — not to stop you, but to make the drift visible so you can choose consciously.

The Drift Model

Scope Definition

At the start of a task, your scope is defined by:

SCOPE ANCHOR:
├── Task statement: "Fix checkout failing for international addresses"
├── Target files: src/checkout/address.ts, src/checkout/validation.ts
├── Target behavior: International addresses should pass validation
├── Branch name: fix/international-address-checkout
└── Estimated files to touch: 2-4

Drift Detection

As you work, every file modification is classified:

Classification	Description	Example
On-scope	Directly addresses the stated task	Fixing the address validation regex
Adjacent	Related to the task, reasonable to include	Updating the test for address validation
Tangential	Same area of code but different concern	Adding types to the checkout module
Drift	Different area, different concern	Refactoring the auth module
Rabbit hole	Deep change triggered by a discovery during on-scope work	Upgrading a dependency because you noticed it was outdated

The Drift Gradient

ON-SCOPE ──── ADJACENT ──── TANGENTIAL ──── DRIFT ──── RABBIT HOLE
   ✓              ✓             ⚠             🔴           🕳️
 "This is       "This is      "This is      "This is     "What year
  the fix"      part of       related but    a different   is it?"
                 the fix"     not the fix"   task"

How It Works

Phase 1: ANCHOR
├── Capture the task statement (from branch name, commit message, or explicit declaration)
├── Identify the target area of the codebase
├── Establish the scope boundary (files, modules, behaviors)
└── Set drift tolerance (tight, normal, or exploratory)

Phase 2: MONITOR
├── For every file modification, classify:
│   ├── Is this file in the target area?
│   ├── Does this change relate to the stated task?
│   ├── Is this change necessary for the task to succeed?
│   └── Would this change make sense as a separate commit/PR?
├── Track accumulated drift:
│   ├── Files touched outside scope
│   ├── Lines changed outside scope
│   └── Time spent outside scope
└── Track scope expansion events (when you discover the task is bigger than expected)

Phase 3: ALERT
├── When drift accumulates past threshold:
│   ├── Name the drift ("You've started refactoring auth — this is unrelated to checkout")
│   ├── Quantify it ("4 files, 87 lines, ~25 minutes of off-scope work")
│   ├── Offer choices:
│   │   ├── STASH: Save off-scope changes for a separate task
│   │   ├── COMMIT SEPARATELY: Make a separate commit for the off-scope work
│   │   ├── EXPAND SCOPE: Acknowledge the scope grew (with justification)
│   │   └── CONTINUE: You're aware and choosing to continue
│   └── Log the decision for later review
└── Resume monitoring with updated scope (if expanded)

Phase 4: SESSION SUMMARY
├── At end of session, report:
│   ├── Time on-scope vs. time drifted
│   ├── Files changed on-scope vs. off-scope
│   ├── Drift events and how they were resolved
│   └── Suggested follow-up tasks for off-scope discoveries

Alert Format

╔══════════════════════════════════════════════════════════════╗
║              SCOPE SENTINEL: DRIFT DETECTED                 ║
╠══════════════════════════════════════════════════════════════╣
║                                                              ║
║  YOUR TASK: Fix checkout for international addresses         ║
║                                                              ║
║  DRIFT:                                                      ║
║  You've been modifying src/auth/middleware.ts for 18 minutes.║
║  This file is not related to checkout or address validation. ║
║                                                              ║
║  HOW YOU GOT HERE:                                           ║
║  checkout/address.ts → noticed untyped import                ║
║  → opened utils/types.ts to add types                        ║
║  → noticed auth/middleware.ts also uses these types           ║
║  → started "fixing" auth types too                           ║
║                                                              ║
║  ACCUMULATED OFF-SCOPE:                                      ║
║  ├── 3 files outside checkout/                               ║
║  ├── 47 lines of changes unrelated to the bug                ║
║  └── ~18 minutes of drift                                    ║
║                                                              ║
║  OPTIONS:                                                    ║
║  [1] STASH off-scope changes, return to checkout bug         ║
║  [2] COMMIT SEPARATELY ("add types to auth middleware")      ║
║  [3] EXPAND SCOPE (justify: "types are prerequisite")        ║
║  [4] CONTINUE (I know, I'll wrap up soon)                    ║
╚══════════════════════════════════════════════════════════════╝

Session Summary

╔══════════════════════════════════════════════════════════════╗
║                SCOPE SENTINEL: SESSION REPORT                ║
║            Task: Fix international address checkout          ║
║            Duration: 2h 14m                                  ║
╠══════════════════════════════════════════════════════════════╣
║                                                              ║
║  FOCUS SCORE: 68/100                                         ║
║                                                              ║
║  TIME BREAKDOWN:                                             ║
║  ├── On-scope:   1h 22m (62%)  ████████████░░░░░░░░         ║
║  ├── Adjacent:      18m (13%)  ██░░░░░░░░░░░░░░░░░░         ║
║  ├── Tangential:    16m (12%)  ██░░░░░░░░░░░░░░░░░░         ║
║  └── Drift:         18m (13%)  ██░░░░░░░░░░░░░░░░░░         ║
║                                                              ║
║  DRIFT EVENTS: 2                                             ║
║  ├── Auth middleware typing (stashed → separate task)        ║
║  └── Utility function rename (committed separately)          ║
║                                                              ║
║  FOLLOW-UP TASKS GENERATED:                                  ║
║  ├── "Add TypeScript types to auth middleware"                ║
║  └── "Rename formatAddress → formatPostalAddress globally"   ║
║                                                              ║
║  TASK STATUS: Bug fixed. PR ready.                           ║
╚══════════════════════════════════════════════════════════════╝

Drift Tolerance Modes

Mode	Threshold	Best For
Tight	Alert after 1 off-scope file or 5 minutes of drift	Bug fixes, hotfixes, time-sensitive tasks
Normal	Alert after 3 off-scope files or 15 minutes of drift	Feature work, standard development
Exploratory	Alert after 6 off-scope files or 30 minutes of drift	Refactoring, investigation, learning a new codebase
Off	No alerts	Freeform hacking, prototyping, creative exploration

When to Invoke

• At the start of every focused task. Set your scope anchor.
• When working on bug fixes (scope drift is most costly here)
• When working against a deadline (every drifted minute hurts)
• When you notice yourself saying "while I'm in here..." (the classic drift phrase)
• During code review prep (to ensure your PR is focused)

Why It Matters

Scope drift isn't laziness — it's a natural consequence of how developers think. You see a problem, you want to fix it. The impulse is productive. But unchecked, it turns a 30-minute bug fix into a 4-hour PR that touches 15 files and is impossible to review.

Scope Sentinel doesn't stop you from doing extra work. It makes sure the extra work is deliberate, not accidental.

Zero external dependencies. Zero API calls. Pure file-change monitoring.