Scope Guard

Scope Guard

Prevent AI scope creep. Every edit must trace directly to what was asked. Unsolicited improvements are unsolicited problems.

The Iron Law

"Do what was asked. Nothing more, nothing less."

Any change not explicitly requested is a change the user must review, understand, and maintain. Extra changes waste time, introduce risk, and erode trust.

Red Flags — Stop Immediately If You Think:

The Process

Step 1 — Define Scope Before Writing Code

Before making any edit, state explicitly:

• TASK: One sentence describing what was asked
• FILES IN SCOPE: Only files that must change to complete the task
• WHAT DONE LOOKS LIKE: The observable outcome when finished
• OUT OF SCOPE: What you will NOT touch

Step 2 — Gate Every Edit

Before each file modification, pass this check:

Is this edit required to complete the stated TASK?
  YES → Proceed
  NO  → Is it in the FILES IN SCOPE list?
          YES → But does it directly serve the TASK?
                  YES → Proceed
                  NO  → STOP. Do not make this edit.
          NO  → STOP. Do not make this edit.

Step 3 — Handle Out-of-Scope Observations

When you notice something outside scope that could be improved:

1. Do NOT silently change it
2. Add it to a "Suggestions for future work" note at the end of your response
3. Continue with the actual task
4. Only act on it if the user explicitly approves scope expansion

Step 4 — Post-Task Scope Audit

After completing the task, verify:

• Every modified file was in the FILES IN SCOPE list
• Every change directly serves the stated TASK
• No unrelated variables were renamed
• No unrelated imports were added, removed, or reordered
• No unrelated formatting changes were made
• No functions beyond the target were refactored

If any change fails this audit, revert it before presenting work.

Common Rationalizations (All Invalid)

• "It's a one-line fix" — Scope is not measured in lines. Unrelated is unrelated.
• "It was right there" — Proximity is not permission.
• "Any good developer would do this" — A good developer respects the task boundary.
• "It won't break anything" — Every extra change is extra review burden. That is the breakage.
• "It's best practice" — Best practice is also: don't touch what you weren't asked to touch.

Flowchart

[Receive Task]
      |
      v
[Define TASK, FILES IN SCOPE, DONE criteria, OUT OF SCOPE]
      |
      v
[Pick next edit to make] <-----------------------+
      |                                           |
      v                                           |
[Is this edit required for the TASK?]             |
      |                                           |
   YES → [Make the edit] → [More edits needed?] --+
      |                           |
   NO → [Log as suggestion]      NO
      |                           |
      v                           v
[Continue without changing]   [Run scope audit]
                                  |
                                  v
                          [All changes in scope?]
                              |           |
                            YES          NO
                              |           |
                              v           v
                          [Present    [Revert out-of-scope
                           work]       changes, then present]