New to Claude Skills? Learn how to install them →

shubhamsaboo on GitHub

Scope Creep Detector

Free

Identify and manage scope creep in code changes.

Get this skill

Free · Opens the source repo

What Scope Creep Detector does

The Scope Creep Detector is a Python-based tool designed to analyze git diffs against a specified intent, helping developers identify scope creep in their changes. It evaluates the differences in code and highlights potential issues such as unrelated files, broad pull requests, and modifications that exceed the original fix. By focusing on the stated intent, the tool provides actionable insights that guide users in making informed decisions about their code changes.

This skill operates entirely offline, ensuring that it does not modify the working tree, index, commits, or branches. It can be run locally on any repository, making it a versatile addition to a developer's toolkit. The user simply needs to provide the repository path and the intent of the changes, and the script will classify the changes accordingly. The output includes a detailed analysis of the changes, categorizing them into in-scope, likely creep, and other relevant signals.

The Scope Creep Detector is particularly useful when preparing for pull requests, as it helps ensure that changes are focused and relevant. It can also assist in identifying unexpected file changes during bug fixes or when assessing the breadth of staged changes. By providing a clear structure for evaluating changes, it aids in maintaining code quality and project integrity.

This tool is aimed at developers who want to streamline their code review process and minimize the risk of introducing unrelated changes. It is especially valuable for teams that prioritize clarity and precision in their pull requests, ensuring that every change aligns with the original intent.

When to use it

Use this skill before submitting a pull request to confirm that the changes align with the stated intent and do not introduce unrelated modifications.

When not to use it

This tool is not suitable for reviewing code correctness, security, or test quality, nor for formatting code or writing commit messages.

What you can build with it

Preparing a Pull Request

Before submitting a pull request, run the Scope Creep Detector to ensure that your changes are focused and relevant to the stated intent.

Identifying Unexpected Changes

Use this tool when a bug fix inadvertently touches unrelated files, helping to clarify the scope of your changes.

Assessing Staged Changes

When unsure if your staged changes are too broad, run the analysis to get a breakdown of what is in scope and what might be considered scope creep.

How to install Scope Creep Detector

View source

1. Install with the skills CLI

npx skills add shubhamsaboo/awesome-llm-apps/scope-creep-detector --agent claude-code

2. Or install it manually

Download the skill folder and drop it into ~/.claude/skills/ for all projects, or .claude/skills/ to scope it to one repo. Restart Claude Code so it picks up the new skill.

Anthropic's agentic coding CLI, and the reference implementation of Agent Skills. Drop a skill folder into ~/.claude/skills and Claude Code loads it automatically whenever a task matches the skill's description. Claude Code docs

Inside SKILL.md

Written by shubhamsaboo

Scope Creep Detector

A one-line fix should not require a reviewer to reverse-engineer fourteen files across three subsystems. This skill compares a git diff with its stated intent, surfaces scope signals, and turns them into keep, split, or justify decisions.

Everything runs locally. The script makes no network calls and does not change the working tree, index, commits, or branches.

When to use

  • Before opening a pull request whose diff may have grown beyond its intent
  • When a bug fix touches unexpected files or subsystems
  • When the user asks whether staged changes are too broad
  • When a diff includes dependency, public API, config, CI, or build changes
  • When the user wants a concrete split plan for a mixed change

When not to use

  • Formatting code, running a linter, or writing a commit message
  • Reviewing correctness, security, or test quality inside an agreed scope
  • Measuring historical project growth across many commits
  • Editing or reverting files without the user's approval

Establish the intent

Use the user's one-line intent when available. Keep it concrete, such as fix null dereference in parser or add retry limit to webhook delivery.

If no intent was given, the script falls back to the current branch name. If that name is generic, detached, or unrelated to the work, ask for one line of intent before treating relatedness as meaningful.

Run the classifier

Run from this skill directory and point --repo at the target repository.

Working tree diff:

python3 scripts/scope_creep.py --repo /path/to/repo \
  --intent "fix null dereference in parser" --json

Staged diff:

python3 scripts/scope_creep.py --repo /path/to/repo --staged \
  --intent "fix null dereference in parser" --json

Branch diff against a merge base:

python3 scripts/scope_creep.py --repo /path/to/repo --base main \
  --intent "fix null dereference in parser" --json

Saved diff or stdin:

python3 scripts/scope_creep.py --diff change.diff --intent "parser fix" --json
git diff --staged | python3 scripts/scope_creep.py --diff - \
  --intent "parser fix" --json

Use --hunk-threshold only when the repository has a documented reason to change the default churn threshold. Do not tune the threshold merely to make a warning disappear.

Interpret the JSON

Read references/scope-signals.md before making a recommendation. Treat the classifier as triage evidence, not proof of authorial intent.

  • in_scope: file paths with at least one intent/path keyword overlap
  • likely_creep: paths without overlap, with the reason and detected signals
  • new_deps: dependencies introduced in supported manifest formats
  • api_renames: nearby removed and added public function or class declarations
  • config_edits: CI, container, build, YAML, and TOML changes
  • stats: churn, subsystem counts, oversized hunks, and formatting-only files

Empty arrays are evidence too. Say that no signal was detected, not that the diff is guaranteed to be in scope.

Recommend keep, split, or justify

Give every item in likely_creep one disposition:

  1. Keep when the path is necessary for the stated intent and the connection is direct. Explain the connection in one sentence.
  2. Split when it can land independently, belongs to another subsystem, or introduces a dependency, API rename, config edit, or large hunk that is not required for the intent. Name the files or hunks for the follow-up change.
  3. Justify when a cross-cutting edit cannot be separated safely. State the invariant or build constraint that requires it and call out reviewer risk.

Prefer split when evidence is ambiguous. Never claim that a zero overlap score proves a file is unrelated. Path vocabulary is a cheap, deterministic proxy.

Write the scope report

Use this compact structure:

  1. Intent and diff source
  2. Files and subsystems touched, with total additions and deletions
  3. In-scope changes
  4. Likely creep with signal evidence
  5. Keep, split, or justify table
  6. Proposed follow-up grouping, if any

Name file paths and hunk headers. For an oversized mixed hunk, explain that the script cannot split it automatically and describe the smallest coherent edit. Ask before applying any split, revert, staging, or commit operation.

Files

  • scripts/scope_creep.py: deterministic unified-diff parser and classifier
  • references/scope-signals.md: signal definitions, thresholds, and limits

Frequently asked questions about Scope Creep Detector

Similar skills