scope-creep-detector skill

by Shubhamsaboo·Shubhamsaboo/awesome-llm-apps·145k stars·Apache-2.0

Analyzes git diffs against a stated intent to detect scope creep, unrelated files, broad pull requests, changes that grew beyond a fix, dependency additions, public API renames, config or CI edits, oversized hunks, and formatting-only files. Use when the user asks whether a change grew beyond the fix, a PR is too broad, or what unrelated stuff they touched, and wants keep, split, or justify guidance. Operates locally and offline.

A100/100content scan

Is the scope-creep-detector skill safe?

Clean: nothing in its files matched our rules. We read 4 files in the folder on 2026-10-25.

No findings.

Install the scope-creep-detector skill

A skill is a folder. Copy it into your agent's skills folder and the agent loads it when the task matches its description.

git clone --depth 1 https://github.com/Shubhamsaboo/awesome-llm-apps.git /tmp/awesome-llm-apps
mkdir -p ~/.claude/skills
cp -r /tmp/awesome-llm-apps/agent_skills/scope-creep-detector ~/.claude/skills/scope-creep-detector

available in every project

In the Claude apps, zip the folder and upload it from the Skills settings. The folder on GitHub

The instructions your agent would load

SKILL.md as published, without the frontmatter. Read it on GitHub

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:

is direct. Explain the connection in one sentence.

Keep when the path is necessary for the stated intent and the connection

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.

Split when it can land independently, belongs to another subsystem, or

invariant or build constraint that requires it and call out reviewer risk.

Justify when a cross-cutting edit cannot be separated safely. State the

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:

Intent and diff source
Files and subsystems touched, with total additions and deletions
In-scope changes
Likely creep with signal evidence
Keep, split, or justify table
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

More skills from Shubhamsaboo/awesome-llm-apps

Aadvisor-orchestrator-workerUse when a task is too large for one model pass, needs parallel research or generation across many subtasks (like researching a dozen competitors at once), or the user asks to orchestrate multiple models, split work across a model team, run an advisor-worker loop, have a stronger model review the plan while cheap workers execute, or says "too big for one model" or "fan this out". Not for single-file edits or tasks one model handles in one pass.
Achatgpt-app-builderDEPRECATED: This skill has been replaced by `mcp-app-builder`. Check if `mcp-app-builder` is available in the skills folder. If not, install it: `npx skills install mcp-use/mcp-use --skill mcp-app-builder` Use `mcp-app-builder` instead of this skill.
Acommit-archaeologistReconstructs why code exists from local git history, including the introducing commit, later changes, current authors, repeated companion files, and likely intent. Use when the user asks "why does this code exist", "who wrote this function and why", or to "explain the history of this function" before a rewrite, refactor, or risky edit. Runs entirely locally.
Adependency-doctorChecks requirements.txt, pyproject.toml, and package.json dependency manifests for surface-level direct-dependency footguns: standard-library shadowing pins, abandoned backports, unpinned dependencies, and obvious intra-manifest conflicts, plus opt-in PyPI yanked releases. Use when the user asks to check a manifest for dependency problems, asks why dependencies won't install or whether anything is wrong with their dependencies, wants a dependency autopsy, or suspects dependency manifest rot. Runs offline by default as a local tool for the user's own project, not repository CI.
Afirst-readerBeta readers for any draft, run by simulating how a real reader experiences it, moment by moment. A skim gate, a no-lookahead timed read producing an attention transcript with quit points, a recall test of what a reader remembers the next day, and a trust ledger of the implied author. Use when the user asks for a beta read, beta readers, test readers, human review, reader review, to read something like a human, to be a first reader, whether a piece holds attention or will actually get read, for a quick read of whether a busy skimmer would even open a post, what readers will remember or take away tomorrow, where readers stop reading or bounce, or why a draft still feels off or hollow after anti-slop or humanizer edits. Final gate before publishing; reports where the reading broke; never rewrites.
Amcp-apps-builder**MANDATORY for ALL MCP server work** - mcp-use framework best practices and patterns.
Amcp-builderDEPRECATED: This skill has been replaced by `mcp-app-builder`. Check if `mcp-app-builder` is available in the skills folder. If not, install it: `npx skills install mcp-use/mcp-use --skill mcp-app-builder` Use `mcp-app-builder` instead of this skill.
Aproject-graveyardScans the developer's machine for dead side projects, autopsies each one from its git history (died at the payments wall, killed by a newer project, finished but never shipped), surfaces their personal death patterns, and picks the corpse most worth resurrecting — then helps ship it. Use when the user mentions abandoned, unfinished, or old side projects, asks "what should I finish", wants to revive or resurrect a project, says "run the graveyard", wonders why they never finish anything, or is about to start a new project that sounds like one they already built. Runs entirely locally.
Athinking-out-loudA contract for what the agent does when a long, messy, stream-of-consciousness ramble arrives (usually voice dictation): act on nothing until the echo brief is approved. The echo audits the entire transfer, mission, locked decisions and constraints, open questions, flips and parked tangents, with the model's inferences and guesses quarantined away from the user's own phrasing, so the user verifies what the model believes, not just what it doubts. Use when the user says "let me think out loud" or wants to ramble a bit before building anything, when a message opens with a speech-to-text preamble like "switching to voice, sorry for typos", when input is a long weakly punctuated stream with restarts and mid-message reversals ("actually no, wait, scrap that idea entirely"), or when the user asks to be interviewed about a fuzzy half-formed idea. Includes an optional capture mode for rambles spread across several messages and an optional targeted interview.

All agent skills → · MCP servers