# Scope Guard

> Use when making code changes to prevent scope creep, over-engineering, and unrelated modifications beyond what was asked. Activates on any task involving file edits to enforce strict scope boundaries, flag unnecessary extras, and ensure changes match the request — nothing more, nothing less. Prevents bloat, YAGNI violations, and unsolicited refactoring.

- Skill: `owen-dev-6174/scope-guard` (Agent Skill)
- Install (CLI): `npx skillmds@latest add owen-dev-6174/scope-guard`
- Raw SKILL.md: https://api.skillmd.com/api/skills/owen-dev-6174/scope-guard/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: owen-dev-6174 (https://skillmd.com/u/owen-dev-6174)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/owen-dev-6174/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:

| Thought | Why It's Wrong |
|---|---|
| "While I'm here, I might as well..." | You are not here for that. Stay on task. |
| "This import is unused, let me clean it up" | Cleanup is not your task. Note it, move on. |
| "This could be refactored to be better" | Better is the enemy of done. |
| "This variable name is inconsistent" | Is renaming in scope? No? Then don't. |
| "I noticed a bug in this other function" | Log it as a suggestion. Don't fix it. |
| "Let me restructure these imports" | Were you asked to touch imports? No. |
| "This pattern is outdated, I'll modernize it" | Modernization is a separate task. |

## 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]
```